Last updated October 22, 2012.

Date is a contributed module that is used on the majority of sizeable Drupal sites. While there is quite a bit of functionality in the Date module, the most important and basic aspects help to make Drupal more powerful (such as use cases relating to editing and formatting date for publishing and events). While on the surface this functionality may seem simple, it’s actually quite complicated when one considers timezone, daylight savings time, localization, and the many formatting/interface challenges.

Fortunately, the most important functionality in the Date module has evolved to a very stable state. There are several potential benefits from moving the most important aspects of Date into Drupal 8 core, including:

  • User Experience: The date-related functionality in Drupal 7 core is fairly limited, and the user experience will be improved by avoiding the need install the Date module to allow for more flexible formatting and UI features.
  • Contributor Experience: The basic elements of Date are important to many contributed modules, so we can deliver a more streamlined and robust tool set for contributors. And we can provide a consistent base for their efforts.
  • Other Drupal 8 Core Features: In addition to improving the current core experience, there are several several other Drupal 8 core initiatives that would benefit from the Date in 8 initiative, in particular:
    • Multilingual: The efforts to further improve localization and multilingual functionality in Drupal core would benefit from improved date configuration and formatting functionality;
    • Entities: Improved date functionality in core would help to unify entity properties and fields through a consistent date field storage format, date editor widget/UI, and date display formatter;
    • CMI: The Configuration Management Initiative (CMI) would benefit from date variables that are CMI compliant. We are investigating storing date formats as CMI compliant configuration files.
    • WSCCI: The Web Services initiative would benefit from consistent JSON-LD serialization of all date fields; and
    • VDC: The recently announced Views in Drupal Core (VDC) initiative would benefit from seeing the Views Date functionality also moved into core.

In light of the stability of Date and above benefits, we have been working on efforts to move several components of the Date module into core for Drupal 8. In particular, the proposed roadmap for the Date in 8 initiative involves a few key elements:

Date Component in Core

Integrating a new Date class in Core which provides a wrapper around the PHP DateTime object in order to deliver better flexibility, functionality, formatting and error handling. The component accepts input in various forms, including string dates, string expressions (like 12AM today), timestamps, an array of date part values (year, month, day), or even another DateTime object, creating a DateTime object from any of them.

Unlike PHP’s basic DateTime class, which does no translation of the formatted display of a date, the component includes integration with the IntlDateFormatter, when available, to translate and adapt the output for calendars other than the Gregorian calendar. The component also tightens up the otherwise lenient error handling of the DateTime class for better validation of input. With this component in core, contributed modules can extend it or rely on it as a basis for lots of additional date, time, and calendar functionality.


Core Date API

The Date API includes a number of helper functions that we’d like to get into core. The most important of these are consistent methods for creating lists of translated and untranslated date values, like day names and month names. The translated values are needed for display and the untranslated values are used as array keys and in css class names. Having a central API for this will help both core and contrib.

Creating a pluggable system for handling these is the only way that core will ever be able to support things like alternative calendar systems, which require not just translation of date parts but alternative values for ‘days’ or ‘months’. There are miscellaneous other helper functions that might be needed to support core functionality that will be added as needed. While much of the current Date functionality will remain in contrib (see below -- e.g., repeats, all day, migrate, iCal. etc.), the most commonly used functionality would become part of core.


Date Form Elements and Date Field in Core

The contrib Date API includes code for Date FAPI elements, datetime elements that can be used on any form, not just on fields, e.g., Date select lists, Date JQuery Pop-Up Calendars, Date text fields, and Date Timezone. One or more of these elements would be integrated in core to allow for an improved interface for managing date fields of any kind. They will also be made HTML5-compatible.

At this point core will have the basic functionality needed to support a Datetime field. The current contrib Date module can store dates in various ways (as integer timestamps, as database-native datetime fields, or as varchar ISO dates). We need to identify the best approach to storing values in the database for core (based both on database and overall load testing) and provide just one storage method in core. The database-native storage method has been removed from core, so the question will be whether to store timestamps in an integer field or ISO dates in a varchar field.

Date fields in contrib have lots of other options, a start and optional end date, ways to limit the granularity of dates, options to choose different methods of timezone handling. Those choices will remain in contrib. The core date field will be a simple date field that has none of those options. The core date field needs to be sufficient for use as a timestamp, an event date, or something like a birthday field in a user profile. The plan is to provide just enough functionality to do that.


Date Views

Time permitting, another task is to incorporate Date Views functionality into core, given that VDC has become a formal Drupal 8 initiative. This will probably take place after feature freeze, since Views is unlikely to be stable before that.


An ongoing task is clearly delineating which functionality will remain in contrib in light of the above, most likely in the form of existing contrib modules (e.g., repeats, all day, migrate, iCal. etc.). The goal for everything that goes into core is to be sure that it is robust enough to support all the kinds of things that contrib might need to do, but leaving it to contrib to actually do those things.

Drupal 8 patches have been posted, and the team will be helping to move the above components into core by feature freeze (particularly incorporating the Date API and Date field in core). Thereafter, efforts will be focused on other core initiatives that would need to be addressed by code freeze (e.g., VDC integration, entity standardization, localization, etc.). Karen and her team will be providing updates on and those who want to get involved can: