422564 - JavaScript Date() off by an hour after DST change

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[George V. Reilly]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12

Firefox 2.0.0.12 is not handling the new DST rules correctly.

According to the Control Panel, my timezone is "(GMT-08:00) Pacific Time (US & Canada)".

This simple HTML + JS fragment should show a time that is one hour earlier than the actual local time.

The time is <span id='now'></span>.
<script type="text/javascript">
var now = new Date();
var hhmmss = now.getHours() + ":" + now.getMinutes() + ":" + now.getSeconds();
document.getElementById('now').innerHTML = hhmmss;
</script>

Also reproes in IE6, but not IE7 or IE8.

If Firefox is built with Visual Studio, see http://msdn2.microsoft.com/en-us/vstudio/bb264729.aspx for the likely explanation of the problem.

Our application displays the current time prominently, so it's very annoying that it's wrong.

Reproducible: Always

Steps to Reproduce:
1. Run the HTML + JS fragment.
Actual Results:  
Current time is, say, 18:54:47, but HTML says 17:54:47.

Expected Results:  
18:54:47.

Comment 1

[Matthias Versen [:Matti]]

Did you try a windows reboot ?

Comment 2

[George V. Reilly]

It reproes on a different Windows box, running XP. Both machines were rebooted automatically ~21 hours ago by Windows Update. It does not repro on Mac OS X.

The repro can be made even simpler.

The time is <span id='now'></span>.
<script type="text/javascript">
document.getElementById('now').innerHTML = new Date();
</script>

Actual:   The time is Wed Mar 12 2008 23:10:32 GMT-0800 (PST).
Expected: The time is Thu Mar 13 2008 00:10:32 GMT-0800 (PST).

Comment 3

[George V. Reilly]

I should clarify for non-US readers that new laws regarding Daylight Savings Time came into effect in the US a year ago. Formerly, DST began on the first Sunday of April. Now DST begins on the second Sunday of March. This year, DST began on March 9th.

Code compiled with Visual Studio 2005 does *not* correctly handle the new DST calculations. A hotfix is available (see link above), but it is not included in Service Pack 1.

Comment 4

[George V. Reilly]

It's easy to confirm that DST handling is the problem.

If I roll the system clock back one week, to March 6th, before the new cutover, then the little script displays the same time as the system clock.

If I roll the system clock forward one month, to April 13th, after the old cutover, the little script also displays the same time as the system clock, except that it now says PDT at the end of the line, instead of PST.

Comment 5

[Bob Clary [:bc] (inactive)]

this is covered by ecma/Date/15.9.5.14.js and ecma/Date/15.9.5.34-1.js which are failing only on windows and occurs on both 1.8 and trunk.

Comment 6

[Bob Clary [:bc] (inactive)]

Attachment: failures

Comment 7

[George V. Reilly]

Mea culpa. This is *not* a widespread problem.

It is caused by the presence of set TZ=PST8PDT in my C:\AutoExec.bat. Per KB932590 (http://support.microsoft.com/kb/932590), the existence of the TZ environment variable will cause the CRT to use the old DST rules. (I can't remember why I set TZ several years ago. It's part of the accumulated mess of files that I bring everywhere with me.)

I've downgraded the severity to minor.

Comment 8

[Bob Clary [:bc] (inactive)]

George, thank you very much for finding that kb. It also seems if the crt is out of date, the bug will be manefested as well. Benjamin, do you know the story about the crt we ship with?

Comment 9

[(not currently active) Ted Mielczarek]

We're using the CRT from Visual Studio 2005 SP1.

Comment 10

[George V. Reilly]

You need to apply the DST hotfix, http://msdn2.microsoft.com/en-us/vstudio/bb264729.aspx, on top of VS2005 SP1 to fix this behavior.

I built Vim with SP1, no hotfix, and it had the same problem. I applied the hotfix and rebuilt Vim, and the problem went away.

Comment 11

[(not currently active) Ted Mielczarek]

We're building the CRT from source, does the hotfix update the CRT source?

Comment 12

[George V. Reilly]

That seems perverse and unnecessary. Why not link to msvcrt.dll or libcmt.lib?

Anyway, the hotfix patches tzset.c and some file with version numbers (crtassem.h?).

Comment 13

[(not currently active) Ted Mielczarek]

We're not doing it for our health or sanity, believe me. We build our own CRT so we can replace the default allocator with jemalloc. If you want that hotfix applied on the build machines, file a separate bug (blocking this) in mozilla.org : Release Engineering. I'd say this is unlikely to get fixed though, given that it only manifests itself if you have the TZ env var set.

Comment 14

[Brendan Eich [:brendan]]

I wouldn't conclude anything about unlikely to get fixed at this point. Let's get the blocking bug filed in any event.

/be

Comment 15

[Bob Clary [:bc] (inactive)]

I've applied kb932391 hotfix to vs2005sp1 on qm-winxp03. The results will appear on the MozillaTest tinderbox.

Comment 16

[Bob Clary [:bc] (inactive)]

with currently bonecho/minefield builds on winxp for dates in mar,apr,oct,nov 2007,2008 ecma/Date/15.9.5.14.js and ecma/Date/15.9.5.34-1.js pass. The tests on qm-winxp02 and qm-winxp03 also pass with updated sdks. -> WFM