Problem/Motivation

The time zone handling of the date module is not always working correctly. The problems date back to days of Drupal 6 and there are now more than 100 open issues related to time zone bugs. This is a plan for a major overhaul of the time zone handling.

For Drupal 7, there is a page describing the Date Locale & Time Zone settings. There are 5 different options for the field setting that describes how dates are processed. This is horribly complex, and to make things worse, behavior has changed over time.

In Drupal 8 the Date project is replaced by the DateTime core module. It processing of time zones is simpler than the current Date module, and can be summarized as follows:

  • When a date or timestamp is created, the site/user time zone is assumed and it is converted to UTC when saved in the database.
  • When a date or timestamp is edited, it is converted from the database representation (UTC) and shown using site/user time zone.
  • There is a display setting to determine how a date or timestamp is shown. This may either be as the site/user time zone, or it may set to an explicit time zone (including UTC).

This much simpler approach will be adequate for most use cases, but misses the setting where we explictly do not want time zone conversions (i.e. where time zone conversions are not working reliably, for dates with no times, for historical dates where timezones are irrelevant, or anytime conversion is unnecessary or undesirable).

Proposed resolution

For most part use the Drupal 8 approach, as described above, but retain the field setting “No time zone conversion” for the explicit use case where time zone conversion is not wanted. In detail:

The current 5 options in field settings will be replaced with just two options:

  1. Default site/user time zone (i.e. default site time zone unless overridden by the user – this is the only option available in Drupal 8).
  2. No time zone conversion (I think we still need this one for some use cases).

If the first option is set for the field, the procedure is similar to one used by Drupal 8, i.e.:

  • When a date or timestamp is created, the site/user time zone is assumed and it is converted to UTC when saved in the database.
  • When a date or timestamp is edited, it is converted from the database representation (UTC) and shown using site/user time zone.
  • There is a display setting to determine how a date or timestamp is shown. This may either be verbatim (as it is in the database), as the site/user time zone, or it may be set to an explicit time zone (including UTC).

If the second option is set for the field, the procedure is this:

  • When a date or timestamp is created, it is saved verbatim (no conversion is done when saving in the database).
  • When a date or timestamp is edited, it is shown as represented in the data base.
  • There is a display setting to determine how a date or timestamp is shown. This may either be verbatim (as it is in the database), as the site/user time zone, or it may be set to an explicit time zone (including UTC).

The development of a new time zone handling procedure will take part in a new branch (7.x-3.x) to not interfere with the continued maintenance of Date 7.x-2.x. The 7.x-3.x shall not show up on the project page, but can only be downloaded using git by people committed to reviewing that branch.

Remaining tasks

  1. Discuss the plan, and incorporate any changes agreed upon in the plan. I will leave at least two weeks for discussions.
  2. Implement the agreed upon solution, making time zone handling robust and reliable.
  3. Documenting the behaviour of the revised time zone handling.
  4. Write expanded test cases for the revised time zone handling, to prevent future breakage.
  5. Write migrate sub-modules to migrate data from Date 7.x-2.x to 7.x-3.x
  6. After making sure the branch is functional, Vijaya Chandran will expose 7.x-3.x branch on the project page for broader testing.
  7. Get it to RTBC, Vijaya Chandran create a tagged relese 7.x-3.0.

User interface changes

TBA

API changes

TBA

Data model changes

TBA

Comments

gisle created an issue. See original summary.

steinmb’s picture

steinmb commented

+1 to the overall suggestion. Strip down the options and try to get something that is robust. What about also bump up the minimum req. PHP version in 7.x-3.x branch? We could get rid of code like this one in DateObject:

public function setTimezone($tz, $force = FALSE) {
    // PHP 5.2.6 has a fatal error when setting a date's timezone to itself.
    // http://bugs.php.net/bug.php?id=45038
    if (version_compare(PHP_VERSION, '5.2.7', '<') && $tz == $this->getTimezone()) {
      $tz = new DateTimeZone($tz->getName());
    }
damienmckenna’s picture

damienmckenna
Location TN, USA
commented

+1 to making PHP 7 a requirement.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

Ok, let me walk that back. +1 for making PHP 5.6 a requirement, and I'm completely open to making PHP 7 a requirement if it helps.

steinmb’s picture

steinmb commented

7.1.x as minimum. Soon 2019 and 5.6 and 7.0 is about EOL https://secure.php.net/supported-versions.php - 7.x-2.x branch would support old PHP as it is.

gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented
Issue summary: View changes

steinmb wrote:

7.1.x as minimum.

IMHO, the EOL schedules shown at PHP.net are of limited relevance.

People are not running PHP from PHP.net – they are running PHP from distributions like Ubuntu and Fedora.

For Ubuntu, this means 14.04 LTS will have security patches of PHP 5.5 backported until April 2019 and that 16.04 LTS will have security patches for PHP 7.0 backported until April 2021. RHEL7 will have security patches for PHP 5.4 backported until June 2024.

It is possible to override the default PHP version of a distribution (for example by adding a ppa like ppa:ondrej/php), but in my experience, doing so may have side effects and it also makes configuration management somewhat harder.

I agree that support for outdated versions with buggy time zone handling that are not part of any major distribution – such as PHP 5.2.6 – should be dropped.

However, I see no point in dropping support for a particular PHP version just for the sake of doing it. What version of PHP to require should follow from the Drupal 7 core requirement and not overridden by a contributed module without a good reason.

That being said, I am not opposed to setting the PHP requirement for Date above 5.3 (current Drupal 7 core requirement) – provided there is a good reason for doing so.

Also, there are ongoing discussions about elevating the minimum PHP version required by the Drupal 7 core. When the core requirement is changed, Date 7.x-3.x will follow suit.

steinmb’s picture

steinmb commented

Looks like core will req. minimum PHP 5.6.x from

Drupal 7 will drop support for older versions of PHP 5 on December 31st, but will continue to support PHP 5.6 as long there are one or more third-party organizations providing reliable, extended security support for PHP 5.

https://dri.es/the-end-of-php-5

Anyway. By moving toward date 7.x-3.x should perhaps all feature req. be moved to this branch for the sake of clarity and order?

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

For now we can pretend 7.x-3.x doesn't exist until there's something to work from, we'll manually pull in changes from the 7.x-2.x as we go.

steinmb’s picture

steinmb commented

Happy new year everyone :)
The issue lists a suggested 7-step plan. Anyone know where we are according to that?

gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented

Anyway. By moving toward date 7.x-3.x should perhaps all feature req. be moved to this branch for the sake of clarity and order?

No, please don't. As Damien McKenna says in #8, the main impetus is still on the 7.x-2.x branch.

In the preliminary discussions with Vijaya Chandran, Damien McKenna and others, it was agreed that this branch should only be about time zone handling, and that all regular and normal progress should take place in the 7.x-2.x branch. The 7.x-3.x would not even be packaged until ready for release.

There is a dedicated team of developers working on the 7.x-2.x branch. The time-zone fixing in 7.x-3.x will be a one-man show tracking the progress in the 7.x-2.x branch, but in no way replace it.

The issue lists a suggested 7-step plan. Anyone know where we are according to that?

We're still at step 1, and still open for discussion.

I am still committed to the project, but I am waiting for 7.x-2.11 to be released to have the cleanest possible start for the 7.x-3.x branch.

gregseb’s picture

gregseb commented

Correct me if I'm off base here, but it looks like the ability to allow users to store a timezone on a per date basis (currently accomplished with the "Date's time zone" option under "Time zone handling) was dropped in the date functionality move to DateTime in Drupal 8 core. There seems to be an ongoing issue for bringing back this behaviour here: https://www.drupal.org/project/drupal/issues/2632040

Is there any intention to preserve this behaviour in this overhaul? Asking since I don't see it in the plan outlined on this issue.

gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented

@gregseb,
thanks for bringing this up.

It is correct that it was dropped from the overhaul plan (issue summary). The reason for this was:

  1. The curent implementation is buggy (as noted in the documentation for "Date's time zone").
  2. It was not clear (at least not to me) what the use case was.

However, the D8 issue you link to provides a good explanation of the use case, and I am sure we shall be able to get it to work correctly now that the use case is understood.

However, I do not think we need to add a third option. All that is needed is to add an explicit time zone field to option 2: "No time zone conversion". If this field is not empty, it means that the unconverted date is in this time zone.

I am open to bringing this back into the overhaul plan. However, before adding this to the issue summary, I would like to hear some opinions about how this should be implemented. Is the implementation proposed in the preceding paragraph adequate, or do we want a third option for this use case (similar to the one proposed for D8)?

gregseb’s picture

gregseb commented

Perhaps I'm missing something, but it doesn't look like they added a third option for me, it looks more like, there's a simple checkbox on the date field asking if you want to additionally store a time zone, then the widget has an additional checkbox to specify whether to expose the custom timezone field or not. Whether the user has chosen the current option 1 or option 2, if these checkboxes are used they can either override the default timezone, or convert the otherwise unconverted datetime value respectively. Although, converting an otherwise unconverted timezone sounds strange to me unless we can guarantee that the datetime given is in UTC.

gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented

@gregseb.
the "third option" is not an reference to the Drupal 8 implementation, but to the proposed implementation in this issue summary. What is suggested in comment #12 is not to expand this to:

  1. Default site/user time zone (i.e. default site time zone unless overridden by the user).
  2. No time zone conversion (I think we still need this one for some use cases).
  3. Date's time zone.

… but instead to add a field to the second option (No time zone conversion) to store an explicit time zone.

The Drupal 8 version has dropped all the five options provided by Date 7.x-2.x, and currently save all dates as UTC (converting from the user's time zone on input, and back to the user's time zone on output - unless overridden).

An alternative to the changes to the plan suggested in comment #12 is to go all the way and copy the Drupal 8 approach in Date 7.x-3.x - including adding the option to store an explicit time-zone with the date.

I agree that we need to cover the use case described in #2632040: [PP-1] Add ability to select a timezone for datetime field. But we have to decide between two alternative approaches:

  1. As described in this issue summary, amended as suggested in comment #12.
  2. Backport Drupal 8 DateTime module, amended as described in #2632040: [PP-1] Add ability to select a timezone for datetime field.
damienmckenna’s picture

damienmckenna
Location TN, USA
commented

I think I need to take over the 7.x-3.x branch to fix the all-day problem, which would push this to 7.x-4.x if it ever happens.

gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented

OK. I was first waiting for a stable release without major issues. And these days I am busy with getting stuff D9 compatible. Just go ahead.