Problem/Motivation

Relative dates set in the Field UI are calculated based on the current time, not Drupal::time().

Steps to reproduce

1. Add a date field to a node.
2. For the date field's default date, select "relative date" of "+2 weeks".
3. Use the https://www.drupal.org/project/datetime_testing module to lock the time (e.g., drush datetime:set 2020-07-07 00:00:00.
4. Create a node. The date for the date field will be +2 weeks from the current time, not from the time that Drupal::time() is set to (2020-07-07).

Expected result:
2020-07-21

Actual result:
2020-10-01 (when tested on 2020-09-17)

When using hook_node_presave(), code like the following will give the correct value based on Drupal::time().

    $drupal_current_timestamp = \Drupal::time()->getCurrentTime();
    // Seconds x minutes x hours x days
    $two_weeks_seconds = 60 * 60 * 24 * 14;
    $twoweekslater_timestamp = $drupal_current_timestamp + $two_weeks_seconds;
    $user->set('field_datetime', MYMODULE_get_formatted_date_from_timestamp("$twoweekslater_timestamp"));

Proposed resolution

Calculate relative dates based on Drupal::time() to enable better testing.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

ptmkenny created an issue. See original summary.

codersukanta’s picture

I was trying to demonstrate the issue, Here are my findings.

  1. Added a date field to a node.
  2. Selected date field's default value to relative date of "+2 weeks".

Default value is working as expected, default value is set to 07-10-2020 as I am testing it on 23-09-2020, Which is right behaviour.

But I can see that the module https://www.drupal.org/project/datetime_testing is not available for drupal 9.
I just wanted to confirm that how did you use datetime_testing module for drupal 9.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Frontmobe’s picture

This behaviour still exists in the Drupal 10.1 / 11.x branches.

Since the the issue does not break anything but instead deals with doing testing the right way, I am changing the category from "Bug report" to "Task" here.

Looking for another issue where this might be addressed, resulted only in the much broader meta issue calling for uses of time() and REQUEST_TIME to be replaced by the time service, like in this issue.

Using the time service here does seem useful because consistent use has clear benefits, as outlined here.