1317364 - Inconsistent DST computation: result depending on local time

Status: RESOLVED DUPLICATE of bug 830304

(Core :: JavaScript Engine, defect, P3)

Description

[lukhnos]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.100 Safari/537.36

Steps to reproduce:

I was trying to create a non-existent Date during the daylight saving time transition. I expected Firefox to adjust the result consistently. Instead, it made the date an hour earlier or later *depending on your computer's local date*.

Here is a concrete example. If you are in America/Los_Angeles, the date 2016-03-13 02:30:00 does not exist (daylight saving time of that time zone starts at 2 AM, so after 01:59:59.999 the next local time is 03:00:00.000).

If I create such a Date instance when my computer is in PDT (say any time in 2016-11-01), the reported date will be an hour ahead:

  x = new Date(2016, 2, 13, 2, 30, 0, 0)  // Date 2016-03-13T10:30:00.000Z
  x.getHours()  // 3

However, if my computer is now in PST, the reported date will be an hour behind:

  x = new Date(2016, 2, 13, 2, 30, 0, 0)  //Date 2016-03-13T09:30:00.000Z
  x.getHours() // 1

I could reproduce this with either FF 48 or FF 49 on macOS. The bug was found on a continuous integration server running Linux, and so it should apply to FF's Linux versions. I suspect this behavior is not a recent change.

To reproduce, set your computer's local time to 2016-11-01 (any time will do), restart FF, run the JavaScript snippet above, then change to 2016-11-14 (any time will do), restart FF, then run the snippet above, and compare the result.




Actual results:

Firefox adjusted the returned Date instance inconsistently. In comparison, Chrome always chooses to make it an hour ahead (turning 2016-03-13 02:30 "PST" into 2016-03-13 03:30 PDT) whereas Safari always chooses to make it an hour behind (turning 2016-03-13 02:30 "PST" into 2016-03-13 01:30 PST).

The problem with Firefox's behavior is not the direction it chooses, but rather that it's inconsistent: the direction it adjusts the Date instance depends on the host's local time.


Expected results:

Firefox should adjust non-existent dates consistently.

The current inconsistency also affects period computations. For example, this snippet advances a date by 2 months, 8 days, and 2 hours, taking DST into account:

  var d = new Date(2016, 0, 5, 0, 30, 30, 500);  // 2016-01-05 00:30:30.500 -08:00
  var e = new Date(d.getTime());  // duplcate d
  e.setMonth(d.getMonth() + 2);   // add 2 months, so 2016-03-05
  e.setDate(d.getDate() + 7 + 1); // add 1 week and 1 day, so 2016-03-13

  // add 2 hours, but 2016-03-13 02:30:30.500 doesn't exist, so should leap
  // forward to 03:30:30.500 (or fall back to 01:30:30.500 if the engine so chooses)
  e.setHours(d.getHours() + 2);

  // Should be either 1 or 3 consistently.
  console.log(e.getHours());

Comment 1

[André Bargull [:anba]]

Also reproducible on Linux.(In reply to lukhnos from comment #0)
> I could reproduce this with either FF 48 or FF 49 on macOS. The bug was
> found on a continuous integration server running Linux, and so it should
> apply to FF's Linux versions. I suspect this behavior is not a recent change.
> 

Yes, this is not a recent change and I'm also able to reproduce the issue on Linux. Fortunately the patch attached to bug 830304 will fix this bug, too!

Comment 2

[André Bargull [:anba]]

Fixed in https://hg.mozilla.org/mozilla-central/rev/b7ef07909cc4


Before (Ubuntu - Time zone is in PDT):
x = new Date(2016, 2, 13, 2, 30, 0, 0); x.getHours()
3

Before (Ubuntu - Time zone is in PST):
x = new Date(2016, 2, 13, 2, 30, 0, 0); x.getHours()
1


After (Ubuntu - Time zone is in PDT):
x = new Date(2016, 2, 13, 2, 30, 0, 0); x.getHours()
3

After (Ubuntu - Time zone is in PST):
x = new Date(2016, 2, 13, 2, 30, 0, 0); x.getHours()
3