Problem/Motivation

The PHP function time() is used directly in core in lots of places (see report.txt for core/ usages). During long requests, this value can change, which can lead to testing difficulties (sporadic and unpredictable results).

Proposed resolution

Most uses of time() should be replaced with $requestStack->getCurrentRequest()->server->get('REQUEST_TIME') or $request->server->get('REQUEST_TIME') to allow for better testing. When using the current request isn't feasible, REQUEST_TIME can be used instead.

time() should remain in cases where the difference between REQUEST_TIME and the current time is explicitly needed, like in the batch functions.

Remaining tasks

  1. Replace most usages of time().
  2. Make sure remaining uses of time() are documented properly.

User interface changes

API changes

Data model changes

CommentFileSizeAuthor
report.txt11.69 KBmpdonadio

Comments

mpdonadio created an issue. See original summary.

tr’s picture

Category: Task » Bug report

This has been the policy/recommendation since 2008 (Drupal 7), so if usage of time() has crept back into core, or perhaps never fully removed from core, then it's a bug...

https://www.drupal.org/update/modules/6/7#time

chi’s picture

$requestStack->getCurrentRequest()->server->get('REQUEST_TIME')

Looks too verbose.

mpdonadio’s picture

Assigned: Unassigned » mpdonadio

Started on this yesterday, so assigning myself until I post a first pass.

Re #3, there is an issue about this (I'll try to dig it up). Using the injected requeststack / request is the only way to reliable test certain scenarios. Using the REQUEST_TIME global is problematic in testing situations.

chi’s picture

@mpdonadio is it possible to create some shortcut public method for this?

mpdonadio’s picture

#5, the request stack is already injected all around core, and so is the current request in a lot of places. Both some from Symfony HTTP Foundation, so a shortcut would mean subclassing and a lot of refactoring. The other option would be to create a new service for getting the current date/time, but I think this would be overkill.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

joachim’s picture

Status: Active » Closed (outdated)

> The other option would be to create a new service for getting the current date/time, but I think this would be overkill.

That has since been done, which makes this issue obsolete.

mpdonadio’s picture

Assigned: mpdonadio » Unassigned