Currently Drupal core doesn't provide much help for date handling, nor even a date field. I've been working on a collection of patches that could make Drupal's core date handling much more robust, provide better ways for contrib modules to extend it, and hopefully lead to a date field in core.
This is the first patch I'd like to propose. This is the basis for everything else I hope we can do.
PHP has had a DateTime class since PHP 5.2. Prior to that it had only some pretty anemic date() and time() functions. The DateTime class is better for lots of reasons. It can accept various kinds of strings and create dates from them, like '10AM today', using functionality similar to the PHP strtotime() function. It is smart about timezone handling. The date() functions have no way to control timezone, but the DateTime class lets you specify it. At the moment, Drupal core uses the DateTime class in just a couple of places, but mostly ignores it.
That class, however, is still lacking a number of things that would make it more useful. It has a format() function, but that function can only create English date strings. It has no way to create a date from an array of date values, which would be very useful in form handling. It doesn't have a __toString() method. It is very lenient about interpreting dates, too lenient if you want to do validation of date inputs. For instance, it will take a date like '2/31/2012' and instead of treating that as an invalid date, it will turn it into '3/2/2012'.
Formatting date output is another issue. Drupal provides translation of formatted output in the format_date() class, but that still has some limitations. There is a new PHP class called the IntlDateFormatter that allows you to specify locales and calendars for much better international date handling. Unfortunately, although that is available by default from 5.3 on, it is not enabled by default, and it seems to be unavailable in lots of fairly ordinary places. OSX doesn't have it enable, for instance. But it would be nice for sites that do have that class available to be able to use it, while still providing some sort of fallback for sites that don't.
We have a custom extension of the DateTime object that we've been using in the Date API to fix some of those problems. I've done a lot of work to clean it up and improve it for D8, and I'd like to propose adding it to core in D8.
The patch actually creates two classes. First there is the DateObject class, which is direct extension of the DateTime class. It adds in the ability to accept various kinds of input values -- a string with an unknown format (the default behavior), a string with a known format (useful to make sure the date will be interpreted as intended since the parse can make mistakes about things like negative years), an array of date parts (useful for form handling), a timestamp, or another Date object.
The class incorporates a way to use the IntlDateFormatter for the format() method, if desired, and otherwise falls back to using the normal format() method. It also tightens up the leniency of the created dates so we can more easily validate the input.
The second class in this patch is an extension of the DateObject class to create a DrupalDate class. This basically extends the DateObject to tie it into Drupal's translation system. I've separated them into two classes since the main class could be useful outside of Drupal, and the second one is Drupal-specific. Then in Drupal we would use the DrupalDate class everywhere.
I have a follow up patch for this one that then changes format_date() to include the same settings array so users could optionally pass in the information needed by the IntlDateFormatter. Then instead of formatting the date in the previous way, it passes that settings array on to the date object so it can use the new format() functionality. I'll post that patch as a separate issue if this one is accepted.
I haven't included in this patch any other changes to core to use these classes, but that can be another follow up patch.
I hope patch will accomplish several things:
- Provide a robust way of handling dates that can be further extended in contrib.
- Provide a basis for doing better date form handling, both in core and in contrib.
- Provide part of the foundation needed to get a date field into core.
So here's my patch.