Forcing a user to enter a date as a specifically formatted string is so last millennium. We're using PHP, so there's absolutely no reason to enter a date the hard way... There's a beautiful function in PHP called strtotime() that magically converts almost any human representation of a date into a timestamp. How much cooler is this?

echo strtotime("now"), "\n";
echo strtotime("10 September 2000"), "\n";
echo strtotime("+1 day"), "\n";
echo strtotime("+1 week"), "\n";
echo strtotime("+1 week 2 days 4 hours 2 seconds"), "\n";
echo strtotime("next Thursday"), "\n";
echo strtotime("last Monday"), "\n";

I coded up support for strtotime() style dates, and I'm testing it on a production box as we speak. If it holds up, I'll submit a patch.

CommentFileSizeAuthor
#6 scheduler-strtotime-6.x-1.3.patch3.5 KBbobthecow
#4 scheduler-strtotime.patch4.03 KBbobthecow
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Eric-Alexander Schaefer’s picture

Eric-Alexander Schaefer CreditAttribution: Eric-Alexander Schaefer commented

I believe people have thought about this before.
I cant test it right now, does it magically convert

"jetzt"
"nächsten Dienstag"
"+1 Woche 2Tage 4 Stunden 2 Sekunden"

?

bobthecow’s picture

bobthecow CreditAttribution: bobthecow commented

You know, you're absolutely right. It's not completely magic. I noticed that when I was writing it, and it bugged me. I wish PHP automatically handled more than just English in the strtotime function. Unfortunately it doesn't.

But it does handle:

2005/08/15 3:52:01 pm
2005/08/15 15:52:01
2005-08-15T15:52:01+00:00
15-Aug-05 15:52:01
Monday, 15-Aug-05 15:52:01
15 Aug 05 15:52:01 +0000
Mon, 15 Aug 05 15:52:01 +0000
Monday, 15 Aug 05 15:52:01 +0000
Monday, 15-Aug-05 15:52:01 UTC
15 Aug 05 15:52:01 +0000

As well as almost about any other standardized, or not-so-standard, date format I could think of. You're right though. It's not fair that non-english speaking users can't use month/day/hour offset, or natural language date strings. But I'm sure everyone would still benefit from the fairly format agnostic interpretation of date/time strings as seen above. It's still fairly magic, especially compared to a "format it exactly like this" text field.

I imagine a more "fair" date string parser could be implemented by wrapping calls to strtotime() in another function that thunked the user/site localized words for 'day', 'month', days of the week, etc, into US English before running strtotime().

Ultimately, it's about 10 lines of code to add the option of a more intuitive date input field. In my implementation, you enter 'strtotime' instead of a date format on the module config page to trigger strtotime() date handling. It's not the default format, it's not forced on you. It's just there if you want it.

And I sure do.

mglover’s picture

mglover CreditAttribution: mglover commented

You're not the only one who wants this, bobthecow. Would you be willing to post a patch?

bobthecow’s picture

bobthecow CreditAttribution: bobthecow commented
Status: Active » Needs review
FileSize
scheduler-strtotime.patch4.03 KB

Here's a strtotime() patch against 6.x-1.2. It's working well on my site. Let me know if you have any problems..

bobthecow’s picture

bobthecow CreditAttribution: bobthecow commented

To use this: enter 'strtotime' in the date format box.

bobthecow’s picture

bobthecow CreditAttribution: bobthecow commented
Version: 6.x-1.x-dev » 6.x-1.3
FileSize
scheduler-strtotime-6.x-1.3.patch3.5 KB

Here's a version bump on the patch, for anyone who wants it. This patch is the same as above, rolled against Scheduler 6.x-1.3

zilla’s picture

zilla CreditAttribution: zilla commented

will this make it into the core of the module at some point? wondering if the devs have any opinion on logical and simple date choices..

what about date popup?

Eric-Alexander Schaefer’s picture

Eric-Alexander Schaefer CreditAttribution: Eric-Alexander Schaefer commented

This collides with #250210: Integrate the new jquery popup calendar from Date module version 2 which is not ready yet. When it is ready I will try to get both things working. Please be patient.
BTW: Testing Bobs patch and sharing the result would speed things up a bit... ;-)

zilla’s picture

zilla CreditAttribution: zilla commented

thanks eric - looking forward to seeing it! this is an excellent module, and in fact it's a feature that i always thought would be built into core considering that drupal is CMS and content is not always 'unpublished' but rather moves through draft and save and schedule dates in a normal content production environment (magazine, newspaper, portal, etc)

jonathan1055’s picture

jonathan1055 CreditAttribution: jonathan1055 commented

You asked for some test results, here is what I have found so far:

  1. The maxlength=25 of the publish_on and unpublish_on input fields needs to be extended, to atleast 50. This is because the time entered is converted into a full string, when using the StrToTime option, for example, when doing a preview of the new node. The format used is the sites date_format_long and this string is often more than 25, so it gets truncated in the input window
  2. Related to this, converting to a string using a format which the admin has specified for display of a date is not necessarily the safest thing to do, because many of these formats are invalid as input to strToTime and cause vaidation failure second time round. Eg I enter a date '30 jan 2009 19:30' and preview the node, the date is converted to 'Friday, 30 January, 2009 - 19:30' (my sites date_format_long), the node looks OK, I hit save and then I get a validation error 'The entered publication date is invalid'. This is a pain, because I have already entered the date and it was ok first time. I suggest you use a format with which you have control and select one which validates second time round
  3. A slight limitation of using strToTime is that this function has to make assumptions on your day/month order within the string. It seems that if you separate the dates with slashes it assumes mm/dd/yyyy but if you use hyphens it is taken to be dd-mm-yyyy. This behaviour may not be obvious for a non-techy user so they may end up getting the date wrong. This would need to be explained in the help beneath the input area
  4. A very minor point, but I don't think we want to see smileys in the form input help text. Sorry. Or am I being boring here?

I hope these comments are helpful. Scheduler is a great module (thanks AjK, Eric and the rest) but this patch is certainly not ready to be committed, as it reduces the excellent interface to a slightly clumsy experience. I am sure the patch could be improved, and it would be worth the effort I think.

Eric-Alexander Schaefer’s picture

Eric-Alexander Schaefer CreditAttribution: Eric-Alexander Schaefer commented

Thank you very much, for testing.Although I would probably not be using this feature I would like to see it implemented.
Unfortunately #250210: Integrate the new jquery popup calendar from Date module version 2 didn't have any progress for the last couple of weeks (months?). So if anyone is willing to help making the date/time input easier, please have a look at the popup-feature.

Eric-Alexander Schaefer’s picture

Eric-Alexander Schaefer CreditAttribution: Eric-Alexander Schaefer commented
Version: 6.x-1.3 » 6.x-1.x-dev

There are time zone issues with the latest patch. I will dig into this this week...

Eric-Alexander Schaefer’s picture

Eric-Alexander Schaefer CreditAttribution: Eric-Alexander Schaefer commented

Oh, by the way, this type of input does not work with the date popup active. So the admin would need to deactivate that module. But it might be needed for other modules. Should we make the use of data popup configurable or deactivate it if the date format is 'strtotime'?

Eric-Alexander Schaefer’s picture

Eric-Alexander Schaefer CreditAttribution: Eric-Alexander Schaefer commented

The time zone issues are easy to resolve.

There are serious issues with using the display date format ("date_format_long") because this may be parsed again later (when editing the node) and that will fail, because it might not be a format recognized by strtotime(). How about this: We do not touch the input format and introduce a checkbox "Allow funny dates" ;-). We could then let _scheduler_strptime() try to parse it and if it fails we pass it to strtotime. When the node is edited the times are rendered using the user provided input format (as it is done now) and if the node is saved again the time can be parsed successfully.

Comment please.

Eric-Alexander Schaefer’s picture

Eric-Alexander Schaefer CreditAttribution: Eric-Alexander Schaefer commented
Status: Needs review » Closed (won't fix)

I can as well close this issue if nobody cares about it.

jonathan1055’s picture

jonathan1055 CreditAttribution: jonathan1055 commented

Hi Eric,
Sorry, I've not been contributing to Scheduler these last few months, got involved with other modules.
Referring to my testing in #10 unless these are fixed then it should not be implemented, so it would need some work. But now that you have spent so much effort to good use on the jquery pop-up, if you want to close this thread, that is fine with me.

Jonathan