Blind Date - use human readable dates in the CP & SAEFs

Thanks. I’ll have to wait to get home now. I’ll updated as soon as I do and let you know.

OK, just tried it and am getting the same error back.

I’m going to send you a PM with another file. For some reason I can’t recreate the issue on my local install here, so I see the issue but can’t test any changes I make…

I’m getting these errors:

Notice: Uninitialized string offset: 0 in .../extensions/ext.blind_date.php on line 95

Notice: Uninitialized string offset: 0 in .../extensions/ext.blind_date.php on line 96

Notice: Uninitialized string offset: 0 in .../extensions/ext.blind_date.php on line 97

Notice: Uninitialized string offset: 0 in .../extensions/ext.blind_date.php on line 98

Warning: Cannot modify header information - headers already sent by (output started at .../extensions/ext.blind_date.php:95) in .../core/core.functions.php on line 296

I removed directory info. I tried 1.2.2 and 1.2.3 - This is such a great contribution - I’d love to get it working!

EDIT: I see now my errors are almost identical to DEA’s - sorry about that!

BTW, I’m doing this from a SAEF and it is actually submitting the entry correctly.

Sorry for the delay - I’ve got a new version (1.2.4) up that corrects the problem both DEA and ruraldreams have posted. Those notices were happening if you installed the extension and never submitted any settings in the CP (even if they were all left blank). Should be all fixed up now 😊

Beautiful. Thanks so much!

Yikes! I just realized I had some debug code in there turned on that would cause things to still break. I’ve turned it off and re-uploaded version of 1.2.4 - sorry for the confusion. Please re-download if you’ve got version 1.2.4. Thanks!

Brian, can this handle multiple fields? IOW can I put in entry_date and expiration_date in the “Punctual to a Fault” option? If so is it comma separated, need ’ around each field, etc.?

Err.. one more thing. I’m trying this on a custom date field and when I click a date it still shows the current time and not the time I’m trying to force. Is this a feature or a bug? :p

Yep it will take multiple values for any of the fields in the settings - separate them with |

The way it works is it does its magic during the submission process - so if you’re in the CP and use the calendar, it will show the current time by default, when you submit it, it will then force that time (or do whatever you have set for that field). If you go back and edit the field it would then display the correct time. In other words it doesn’t mess with the javascript function that is used for the calendar - it does its stuff when you submit the entry.

Wonderful, thanks!

This extension seems to be what I need to simplify date entry for the SAEF I’m using for an “Events/Calendar” page.

I just installed but seem to be missing something because though my SAEF now accepts all sorts of formatting, Blind Date is not generating want is intended; e.g. date entered > blind date result 06/25/2007 > 06/24/2007 11:01pm 6/30/2007 > 06/29/2007 11:01pm 07-15-2007 > 08/27/13 11:01pm (it seems to me that the BD ext. does not like “-“) 07/15/2007 > 07/14/2007 11:01pm

The 1hr offset from the default entry time of 12:01am indicates to me a missing setting. But I’m not sure where that would need to go? Also, the fact that the “-” is accepted but causes oddities it worrisome to me. How can I prevent this from occurring, or generate a formatting error message to prevent the entry from posting?.

I suppose, back to my original intent, is there a way to lock in a simple date format of MM/DD/YYYY or YYYY/MM/DD - anything else would generate a formatting error message?

Thanks.

This extension seems to be what I need to simplify date entry for the SAEF I’m using for an “Events/Calendar” page. I just installed but seem to be missing something because though my SAEF now accepts all sorts of formatting, Blind Date is not generating want is intended; e.g. date entered > blind date result 06/25/2007 > 06/24/2007 11:01pm 6/30/2007 > 06/29/2007 11:01pm 07-15-2007 > 08/27/13 11:01pm (it seems to me that the BD ext. does not like “-“) 07/15/2007 > 07/14/2007 11:01pm The 1hr offset from the default entry time of 12:01am indicates to me a missing setting. But I’m not sure where that would need to go? Also, the fact that the “-” is accepted but causes oddities it worrisome to me. How can I prevent this from occurring, or generate a formatting error message to prevent the entry from posting?. I suppose, back to my original intent, is there a way to lock in a simple date format of MM/DD/YYYY or YYYY/MM/DD - anything else would generate a formatting error message? Thanks.

hothousegraphix,

Sorry for the delay - father’s day weekend ended up pretty busy here.

I had a similar situation with the time shift on a server I tested on. The thing about dates/times entered into the system is that it interacts with settings in many different places. The server date/time, the localization settings for EE as well as per user, , as well as daylight savings time. Unfortunately I don’t have an exact, “Do this and your problem will be solved,” answer because all blind date does is take the date supplied and apply the PHP function strtotime to that string. After that happens it is entered into the system, and that is when EE does it’s magic and applies all the localization, daylight savings, etc.

What I did when I encountered the problem was to check the server date/time to make sure it was correct, the daylight saving setting to make sure that was correct, then individually the localization options for EE, for the user making the post. I think I ended up having to use the localization override in the localization preferences - the option “Honor the Daylight Saving Time setting associated with each section entry?” - set that to “no”.

Let me know if that helps - if not we can figure something else out.

For the other questions - the formats it will accept is simply up to the strtotime function once again. Here’s more info on what it will and won’t accept: linky.

At this point EE doesn’t have an extension hook to take over the validation process - so when it encounters something it doesn’t understand it throws the generic error message for a date/time mismatch. You can go in and modify that text manually if you like, but that language file will probably be over-written when upgrading EE which is why I don’t do it with Blind Date.

At this point there isn’t a way to lock in a specific format required, and really that goes a bit against what I want Blind Date to do. The system itself requires a specific format, at BD removes that requirement (although you’re right, it does break for that style formatting you show, I assume because the US format can and is easily confused with the European format, and there’s no ‘right’ way between the two).