342068 - JavaScript's getTimezoneOffset method returns wrong value when the TZ environment variable is set

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Alek Davis]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

My PC's local time zone is set to [(GMT -08:00) Pacific Time (US & Canada); Tijuana], with daylight savings turned on. The getTimezoneOffset method must return 420, but no matter which time zone I use, the value returned by FireFox is always -60. In IE 6, the return value reflects the currently specified time zone.

Reproducible: Always

Steps to Reproduce:
1. Set computer's time zone to [(GMT -08:00) Pacific Time (US & Canada); Tijuana] or anything that is more than hour different from GMT (UTC).
2. Enter the following in the address bar: javascript:alert((new Date()).getTimezoneOffset()); 


Actual Results:  
The pop-up dialog will show -60.

Expected Results:  
The pop-up dialog must show 420 (or the time difference reflecting the offset from GMT).

I could not find an appropriate category to file this bug under (such as client-side scripting, or JavaScript), so I filed it under General.

Comment 1

[Phil Ringnalda (:philor)]

Do you have an environment variable named TZ defined? Tail end of bug 173431.

Comment 2

[Alek Davis]

Hmmm, I have the TZ environment variable, which is set to "TZ=C:\Program Files\WinZip\WINZIP32.EXE ^.TZ". It looks like something added by WinZip. So I removed this environment variable and now the getTimezoneOffeset returns the right value. I read the thread for bug <a href=https://bugzilla.mozilla.org/show_bug.cgi?id=173431>bug 173431</a>, and I kinda see what happens here. If FireFox uses some Windows API to get local time, and this API relies on the value of the TZ environment variable, it must be the problem of this API, most likely the Microsoft bug (at the least they should check the value of this environment variable to make sure that it actually defines the time zone and not something else). On the other hand, my question to Mozilla folks would be, why does IE work correctly if TZ contains something unexpected? Are they calling a different API? Should FireFox call the same API? Anyway, thanks for the feedback. At least now I know what's going on. 

Comment 3

[André Bargull [:anba]]

We're now using ICU to read the default time zone and ICU reads the default time zone via GetDynamicTimeZoneInformation, so setting "TZ" under Windows doesn't have any effect anymore (except for the compatibility code in js::DateTimeInfo::internalResyncICUDefaultTimeZone(), but that code only accepts a handful of time zone ids). So probably fixed by bug 1346211.