Closed Bug 1583208 Opened 6 years ago Closed 5 years ago

Timezone handling in Date is wrong, and documentation is wrong

Categories

(developer.mozilla.org Graveyard :: General, defect)

Product:
developer.mozilla.org Graveyard
Component:
General
Platform:
x86_64
Windows 10
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: jujjyl, Assigned: cmills)

Details

(Keywords: in-triage)

STR:

<html><body><script>
document.body.innerHTML += 'Current local time: ' + new Date().toString() + '<br><br>';

var d = new Date();
d.setMonth(0);
document.body.innerHTML += 'Date object for January this year: ' + d.toString() + '<br>';
document.body.innerHTML += 'Timezone offset from Date object from January this year: ' + d.getTimezoneOffset() + '<br><br>';

var d = new Date();
d.setMonth(6);
document.body.innerHTML += 'Date object for July this year: ' + d.toString() + '<br>';
document.body.innerHTML += 'Timezone offset from Date object from July this year: ' + d.getTimezoneOffset() + '<br><br>';

document.body.innerHTML += 'Date object for January at year 2000: ' + new Date(2e3, 0, 1).toString() + '<br>';
document.body.innerHTML += 'Date object for July at year 2000: ' + new Date(2e3, 6, 1).toString() + '<br>';
</script></body></html>

Try it out live at http://clb.confined.space/dump/browser_timezonetest.html

Observed:

On my Windows PC with Firefox 69.0.1 with Finland local Summer time zone +3 GMT still in effect, the page prints

Current local time: Mon Sep 23 2019 16:19:32 GMT+0300 (Eastern European Summer Time)

Date object for January this year: Wed Jan 23 2019 16:19:32 GMT+0200 (Eastern European Standard Time)
Timezone offset from Date object from January this year: -120

Date object for July this year: Tue Jul 23 2019 16:19:32 GMT+0300 (Eastern European Summer Time)
Timezone offset from Date object from July this year: -180

Date object for January at year 2000: Sat Jan 01 2000 00:00:00 GMT+0200 (Eastern European Standard Time)
Date object for July at year 2000: Sat Jul 01 2000 00:00:00 GMT+0300 (Eastern European Summer Time)

On another Windows PC with Firefox 69.0.1 located in Kaunas, Lithuania, the page prints

Current local time: Mon Sep 23 2019 16:22:44 GMT+0300 (Eastern European Summer Time)

Date object for January this year: Wed Jan 23 2019 16:22:44 GMT+0200 (Eastern European Standard Time)
Timezone offset from Date object from January this year: -120

Date object for July this year: Tue Jul 23 2019 16:22:44 GMT+0300 (Eastern European Summer Time)
Timezone offset from Date object from July this year: -180

Date object for January at year 2000: Sat Jan 01 2000 00:00:00 GMT+0200 (Eastern European Standard Time)
Date object for July at year 2000: Sat Jul 01 2000 00:00:00 GMT+0200 (Eastern European Standard Time)

  1. Note how the timezone offsets are different depending on the month in question when the date is derived from current time.

  2. Note also how the timezone offsets are different also when the date is derived from year 2000, when done on a computer based in Helsinki, Finland in first listing.

  3. But note on the contrary how the timezone offsets are the same when the date is derived from year 2000 when done on a computer based in Kaunas, Lithuania, in the second listing.

Expected:

A. The page https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getTimezoneOffset states

"The getTimezoneOffset() method returns the time zone difference, in minutes, from current locale (host system settings) to UTC."

"// expected output: your local timezone offset in minutes
// (eg -120). NOT the timezone offset of the date object."

The above repro shows this is not the case. The time zone differs depending on the way the Date object is constructed, (using new Date() vs new Date(yyyy, mm, dd)), and depending on which timezone the code is run.

B. Page https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date states

"Date objects contain a Number that represents milliseconds since 1 January 1970 UTC."

the above test shows that this is not accurate. The above test shows that Date objects must contain two Numbers, msecs since 1 Jan 1970, and the timezone the time should be represented relative to. I.e. Date objects (as currently implemented) are not timezone agnostic.

C. On page https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date

"When no parameters are provided, the newly-created Date object represents the current date and time, specified in the local time zone, as of the time of instantiation."

The wording says that "new Date()" creates a Date object that represents the msecs Number in current time zone, and the Date object has a timezone offset according to the current local time zone. This wording can be read to suggest (via exclusion) that this behavior is specific to this new Date() ctor, and that the other ctors that do take in parameters, do the opposite, i.e. specify UTC times.

For example, how does the ctor

new Date(year, monthIndex [, day [, hours [, minutes [, seconds [, milliseconds]]]]]);

behave with respect to time zone? Should new Date(2013, 6, 1) represent 1st of July 2013 in local time zone, or in UTC time zone? It would be good for the documentation to specify that. Based on the test page above, it seems to be local time zone based, and not UTC, but the documentation on parameterless new Date() suggests it should be UTC based. Even then, the resulting time zone varies based on where it is called (either daylight savings get included if called in Helsinki, or daylight was not included if called in Kaunas)

Summary: Timezone handling in Date is wrong, or documentation is wrong → Timezone handling in Date is wrong, and documentation is wrong

This bug was seen to occur on Firefox on Windows, but not on Chrome or Edge on Windows.

Curiously, on Mac, Chrome browser is exhibiting the same issue (DST does not get included depending on which timezone one calls the functions), whereas Firefox worked without issues.

Date is a JS feature, not DOM. -> JS

Component: DOM: Core & HTML → JavaScript Engine

This sounds more like a documentation issue than an implementation issue, therefore moving to "developer.mozilla.org - General" component for further triaging.

  1. Note also how the timezone offsets are different also when the date is derived from year 2000, when done on a computer based in Helsinki, Finland in first listing.

  2. But note on the contrary how the timezone offsets are the same when the date is derived from year 2000 when done on a computer based in Kaunas, Lithuania, in the second listing.

Lithuania didn't observe DST in year 2000, but instead was GMT+2 all year-round.

A) 20.3.4.11 Date.prototype.getTimezoneOffset ( ) specifies that getTimezoneOffset returns the time zone offset including daylight savings.

The Description paragraph on MDN mentions this, too:

The time zone offset returned is the one that applies for the Date that it's called on. Where the host system is configured for daylight saving, the offset will change depending on the date and time that the Date represents and that daylight saving applies.

B) Date objects only include the difference to the start of the Unix epoch per 20.3.5 Properties of Date Instances, but most Date.prototype methods convert from UTC to local time before returning a result resp. processing inputs, e.g. Date.prototype.toString returns the date-time in the local time zone, whereas Date.prototype.toUTCString doesn't perform any local time zone adjustments.

C) The zero argument Date constructor uses the current time (of the current time zone); the single argument constructor uses the input value as UTC time; and when more than one argument is present the input date-time is converted from local to UTC time.

Component: JavaScript Engine → General
Product: Core → developer.mozilla.org
Version: 69 Branch → unspecified
Assignee: nobody → cmills
Flags: needinfo?(cmills)
Keywords: in-triage

(In reply to André Bargull [:anba] from comment #3)

Lithuania didn't observe DST in year 2000, but instead was GMT+2 all year-round.

Wow, learn something new, even though Lithuania adopted DST in 1941, it did not have DST in year 2000. Thanks for the clarification, that explains what we are seeing. Then this bug is indeed rather an opportunity to clarify documentation.

I'm not clear on what needs to be updated in the documentation here. Can you provide some simple clarification?

Florian is our resident JS docs expert, so I've ni'ed him on here so he can take care of it.

BTW, for future reference, MDN docs bugs are now submitted at https://github.com/mdn/sprints/issues

Flags: needinfo?(cmills) → needinfo?(fscholz)
MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
Product: developer.mozilla.org → developer.mozilla.org Graveyard
Flags: needinfo?(fscholz)
You need to log in before you can comment on or make changes to this bug.