Closed
Bug 487897
Opened 15 years ago
Closed 6 years ago
Date object has wrong hour for new year's, 1970 in BST/IST time zone
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
DUPLICATE
of bug 1346211
People
(Reporter: apeller, Unassigned)
References
Details
(Whiteboard: [needs owner])
>>> new Date(1970,0,1,0,0,0,0) Thu Jan 01 1970 01:00:00 GMT+0100 (IST) >>> new Date(1970,0,1,0,0,0,0).getHours() 1 The result ought to be '0' for midnight, and it is nearly everywhere. Strangely, on the Mac, when the timezone is set for Britain or Ireland (but not other locations GMT+1) this returns "1".
Reporter | ||
Comment 1•15 years ago
|
||
Confirmed on FF3.0.3 on Ubuntu also
Reporter | ||
Comment 2•15 years ago
|
||
Confirmed on Minefield nightly Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091029 Minefield/3.7a1pre
Reporter | ||
Comment 3•15 years ago
|
||
and I know, this code should be using UTC, but I'd argue that this is still a bug in local time unless it happened to be a daylight savings shift or something like that.
Comment 4•15 years ago
|
||
Brian: Weren't you looking at some timezone issues in the past?
Comment 5•15 years ago
|
||
I looked into some issues to do with half-time-zones (such as Venezuela -- or parts of it?) and the way we calculate offsets. It's possible we're missing some weird edge-case here. One of the JS peers would probably be best for pursuing this, though.
Comment 6•15 years ago
|
||
It would be useful to know when this behavior appeared, should be easy to bisect for automatically. It would also be instructive to know what the other browser-vendors do here.
Reporter | ||
Comment 7•15 years ago
|
||
I don't know if or when this regressed in Firefox. I believe the bug was first reported for FF 3.0 (Mac and Linux) I just tried in Safari and I get the expected result getHours()==0
Comment 8•15 years ago
|
||
(In reply to comment #5) > One of the JS peers would probably be best for pursuing this, though. Hey, that's you! But let's see what Igor thinks. :)
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: [needs owner]
Version: 1.9.0 Branch → Trunk
Comment 9•14 years ago
|
||
You can see this bug in action here: http://docs.dojocampus.org/dijit/form/TimeTextBox - Click on "View Example" then click on the time box; in firefox the interval between times is 75 minutes, on chromium it is 15 minutes. This was originally reported as a bug in Dojo at http://bugs.dojotoolkit.org/ticket/9107
Comment 10•12 years ago
|
||
I can replicate this on Mac running 9.0.1!
Comment 11•11 years ago
|
||
Bug still present in Firefox 20.
Assignee | ||
Updated•10 years ago
|
Assignee: general → nobody
Comment 12•9 years ago
|
||
The bug is also reproducible on Firefox for Android 36.0.4, only if timezone is set to GMT+00:00 Greenwich Mean Time. Time is also incorrect for 1915-01-01. Test code: alert(new Date(1915, 0, 1)); // Thu Dec 31 1914 23:00:00 GMT+0000 (BST) alert(new Date(1970, 0, 1)); // Wed Dec 31 1969 23:00:00 GMT+0000 (BST)
Comment 13•9 years ago
|
||
The Dojo TimeTextBox example is still broken under Firefox 35.
Comment 14•9 years ago
|
||
Image comparing Firefox to Chromium: http://i.imgur.com/0oqzYBW.png Platform Linux Locale en_GB
Comment 15•7 years ago
|
||
Still an issue on OSX v50.0.2 - 7 years after bug was reported
Comment 16•7 years ago
|
||
Hmm, on FF49 (on a Mac set to GMT), and similarly on FF 45 (ESR) I now get this result: > new Date(1970,0,1,0,0,0,0) Date 1969-12-31T23:00:00.000Z > new Date(1970,0,1,0,0,0,0).getHours() 23 Also incorrect, but in the other direction.
Comment 17•6 years ago
|
||
I'm caught similar issue: > new Date('2015-10-23T00:00:00+06:00').toLocaleString() > result: "23.10.2015, 0:00:00" (correct) but > new Date('2015-10-23T00:00:00+06:00').getHours() > result: 1 (wrong, should be 0) Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0
Comment 18•6 years ago
|
||
This should be fixed in Firefox 63 (bug 1346211) which is about to be released next week.
Comment 19•6 years ago
|
||
Dup'ing forward to bug 1346211 which should have fixed this problem. Please reopen if the issue is still present. Thanks!
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Comment 20•4 years ago
|
||
This doesn't seem to be fixed when using system ICU, at least the test fails
non262/Date/time-zones-historic.js: rc = 3, run time = 0.03141
/data/GNOME/DEB-build-area/mozjs68-68.5.0/js/src/tests/non262/Date/shell.js:146:9 Error: Assertion failed: got "Thu Jan 01 1970 01:00:00 GMT+0100", expected "Thu Jan 01 1970 00:00:00 GMT+0100"
Stack:
inTimeZone@/data/GNOME/DEB-build-area/mozjs68-68.5.0/js/src/tests/non262/Date/shell.js:97:13
@/data/GNOME/DEB-build-area/mozjs68-68.5.0/js/src/tests/non262/Date/time-zones-historic.js:4:1
TEST-UNEXPECTED-FAIL | non262/Date/time-zones-historic.js | (args: "") [0.0 s]
Could the MOZ_SYSTEM_ICU codepath be fixed as well?
Comment 21•4 years ago
|
||
Can you create a new bug report for the system ICU issue? Thanks!
You need to log in
before you can comment on or make changes to this bug.
Description
•