Fixed date values drift by GMT offset when re-saved [#1875866]

When adding a fixed date condition to a rule, re-saving the condition adds or subtracts the difference between the local time and GMT each time.

My timezone in Regional settings is set to "America/Toronto", which is currently GMT -0500.

Create a condition for site:current-date, operator is greater than, data value 2012-12-28 06:00:00.
Edit the condition. The form's data value is displayed as 2012-12-28 11:00:00, which is 5 hours ahead of the previously saved value.
Save the condition.

Repeating these steps causes the data value to drift by +5 hours (or the difference from GMT) each time. It looks like this behaviour comes from RulesDataUIDate::inputForm(), which runs the saved timestamp through gmdate() each time the form is displayed.

Comment	File	Size	Author
#4	rules-format_date-1875866-3.patch	2.17 KB	weiseng
#4	7.x-2.x: PHP 5.3 & MySQL 5.5, D7 Patch Failed to Apply PHP 7.2 & MySQL 5.5, D7 Patch Failed to Apply

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

star-szr

he/him

English

CreditAttribution: star-szr commented 28 December 2012 at 21:45

Title:

Value of fixed date comparison condition drifts when re-saved

» Value of fixed date data value drifts when re-saved

Re-titling because I don't think this bug affects only conditions, it looks like it would affect the schedule functionality as well.

Comment #2

star-szr

he/him

English

CreditAttribution: star-szr commented 28 December 2012 at 21:59

Title:	Value of fixed date data value drifts when re-saved	» Fixed date values drift when re-saved
Component:	Rules Core	» User Interface

Clearer title and technically this is a Rules UI bug.

Comment #3

BrightBold

she/her

English

Boston, MA

CreditAttribution: BrightBold commented 21 November 2014 at 02:38

Title:	Fixed date values drift when re-saved	» Fixed date values drift by GMT offset when re-saved
Issue summary:	View changes

I can confirm this is still a problem in the latest dev.

Comment #4

weiseng CreditAttribution: weiseng commented 23 September 2015 at 03:20

File	Size
rules-format_date-1875866-3.patch	2.17 KB
7.x-2.x: PHP 5.3 & MySQL 5.5, D7 Patch Failed to Apply PHP 7.2 & MySQL 5.5, D7 Patch Failed to Apply

Display the datetime using system default timezone instead of gmdate() to avoid confusion.

Comment #5

weiseng CreditAttribution: weiseng commented 23 September 2015 at 03:21

Status:

Active

» Needs review

Comment #6

Luxian

he/him

Romanian

Zurich Area

CreditAttribution: Luxian at Consenda for Consenda commented 9 May 2018 at 09:59

Status:

Needs review

» Needs work

Thanks @weiseng for the patch. It made my life easier today.

As for review, my only complain is regarding the field description text:

+++ b/ui/ui.data.inc
@@ -354,20 +354,20 @@ class RulesDataUIBoolean extends RulesDataUI implements RulesDataDirectInputForm
+    $form[$name]['#description'] = t('The date in system\'s default timezone. You may enter a fixed time (like %format) or any other values in GMT known by the PHP !strtotime function (like "+1 day"). Relative dates like "+1 day" or "now" relate to the evaluation time.',

1. Maybe we can get away by not mentioning the timezone at all because it's confusing. First of all - I'm not sure what "system" means (Drupal or server). And even if it refers to Drupal system, it can be user's timezone and not the default Drupal timezone. The timezone used is set by Drupal according to the value returned by drupal_get_user_timezone() during bootstrap.

2. There is still a 'GMT' mention in that string.

Proposal:

Fixed time (like %format) or any other values known by the PHP !strtotime function (like "+1 day"). Relative dates like "+1 day" or "now" relate to the evaluation time.