Current Version is: 1.3

1.3 NOTES: Added custom error message to make it more understandable. Added the ‘sweaty palms’ setting that now actually does something   Read the setting section below for more info.

Here’s a little extension to help date entry, both in SAEF forms and in the CP. Many times the default date formatting (YYYY-MM-DD HH:MM) is very confusing and not very user friendly. Blind Date applies a little date lovin for those in need.

It will accept any user readable date - if you can understand it Blind Date should be able to. Keep in mind that this extension relies heavily on the strtotime() PHP function, and as such that function is what determines whether a date is readable or not. Here’s some documentation about what date formats are readable: date input formats

When a date is found that can’t be parsed, it will throw a custom error (you can change this in the language file). It does a heroic job at attempting to understand dates though - supplying Jan 33rd will result in Feb 2nd for example - Blind Date is desperate for any action it can get!

Personality Quirks: (helpful tips)
• Blind Date will cruise all date fields in the system (both SAEF and CP) - including entry_date, edit_date and expiration_date.

• By default, if no year is specified, then the current year is used. If a time is given along with the date that time will be honored - if no time is given it defaults to 12:01 AM.

• Be careful what you ask for! Your preferences (settings) can potentially lead to a horrible Blind Date experience! If you set a preference for one of the default system fields (like entry_date) then it applies to EVERY entry_date field throughout the system. You’ve been warned!

Helpful hints to make your Blind Date a successful one (settings):

Separate fields with a |.

Thinking Long Term? (force future date) - List the fields you would like to force into the future . Example: If today is March 15, 2007 and Jan 3rd is supplied, the resulting date will be Jan 3rd, 2008.  If Jan 3rd 2005 is entered, the resulting date will be Jan 3rd, 2008. (this is handy for using with the ‘expiration_date’ field.)

Punctual to a Fault (force 12:01 AM) - Did you say something embarrassing, or maybe spill red wine on your date’s miniskirt? Rewind the clock - fields set here are forced to use 12:01 AM as the entry time.

Fashionably Late (honor time, otherwise 11:59 PM) - Want a long date but don’t want to seem desperate? Any field listed here will honor a time if it is given, and if no time is given will use 11:59 PM.

Disastrously Late (force 11:59 PM) - Oh boy. Ignore the time given and show up at 11:59 PM, no ifs, ands or buts. You might not be on time, but at least you have the day right. Hope you brought flowers.

Sweaty Palms? - If you have sweaty palms, it will force an empty expiration_date field to take on the same date as the entry_date field, but with a time of 11:59 PM (it expires at the end of the day).

There’s a bug in the file attachments functionality here. Can you put the code up for download somewhere else? I’d love to try it. Love the name, btw.

I hadn’t realized that. I’ve got a copy mirrored here for anyone who would like to try it out:

EDIT: file removed

Can this also be made to work with the backend?

Sue Crocker - 16 March 2007 06:42 AM

Can this also be made to work with the backend?

Yeah I can’t think why it wouldn’t. Let me look into that.

Sue that was a good idea - thanks. I’ve added the ‘attractive back-end’ option - set that to yes and it will work in the CP as well.

Here’s a link to version 1.1 (until the forums get worked out):

Blind Date 1.1

Oh - just so you know you should disable the extension and then re-enable it for the changes to take place

I disabled it before uploading the newer version. I’ve been bit by that before.

It works for the front end and back end. The one thing I did what to have happen is that if I click on an expiration date from the calendar, I want the date generated that way to automatically make it 12:59 PM, not to rely on me clearing the field.

Does that make sense? Clearing out the time portion works, but it also makes it not automatic for clients.

Sue Crocker - 16 March 2007 02:00 PM

I disabled it before uploading the newer version. I’ve been bit by that before.

It works for the front end and back end. The one thing I did what to have happen is that if I click on an expiration date from the calendar, I want the date generated that way to automatically make it 12:59 PM, not to rely on me clearing the field.

Does that make sense? Clearing out the time portion works, but it also makes it not automatic for clients.

Ahh I see. That’s a different beast altogether. I’ll look at adding that in - it will probably be a bit before I have time to do it however.

Sue - when I do get a chance…

Would this be an ok solution: If someone uses the calendar and gets the javascript it would show the current time until it was submitted, when it would change to the forced 12:59.  There would be a field in the settings that is for “ignore given times” - it’s a text input for the fields you want to override. 

Or would that be too confusing? If I do the above it’s just a simple addition to the extension - otherwise I have to hook in and start messing around with the javascript that does the dates which is more work (and I hate javascript ... )

No, that wouldn’t be too confusing. I don’t want to deal with Javascript either.

I really appreciate you doing this. I can tell the client to not worry about the actual time of the item.

Sue I’ve uploaded a new version (1.2).  Things have changed rather dramatically so be sure to read the original post for the new settings.

I think downloads are working now from the forums so I’m not going to mirror unless someone asks

Cheers!

Brian I love it.  I’ve been able to throw pretty much any date string at it (2 months, yesterday, tomorrow etc) and it works great.

But if I enter complete jibberish it doesn’t throw an error.  Or if I misspell something for example, 2 Desember 2005.  Going by what you said below, if it can’t find a date it should throw an error right?

Brian M. - 15 March 2007 05:02 PM

When a date is found that can’t be parsed, it will throw the normal error for an incorrectly formatted date (including mentioning that it needs to be in YYYY-MM-DD HH:MM format even though it doesn’t).

I looks like it’s because you’re checking for

Wheras the return of strtotime($_POST[$field]) if it didn’t find a date would be FALSE.

When attempting to use 1.2, I get the following error message:

EE Version: 1.5.2 20070302 EECore I’m only using two of the

smallbeer - you’re right. Looks like they changed the strtotime() function with PHP 5 (it used to return -1 on a bad date). Should work with PHP 5 now as well - let me know if you still don’t see errors.

Sue - oops. I should have that fixed now as well.

New version 1.2.1 in the original post.

Lovely.  It’s a work of beauty.

My only feature request would be to somehow hook into the validation error and replace it with something a little more helpful for those fields using the extension.

Thanks smallbeer

That’s a good idea about changing the validation error - I’ll look into that when I get some time.

This sounds great - something like this will be muchly appreciated by my clients. Thanks so much for releasing it, can’t wait to try it out!