173431 - getTimezoneOffset incorrect during DST

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Justin Matlock]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705)
Build Identifier: Mozilla/1.2a

getTimezoneOffset is returning 300 in the Eastern Time Zone during daylight 
savings time.

The ECMA specs state:

15.9.5.22 Date.prototype.getTimezoneOffset()
Returns the difference between local time and UTC time in minutes.

1. Let t be this time value.
2. If t is NaN, return NaN.
3. Return (t - LocalTime(t)) / msPerMinute.

By these specs, Mozilla is returning the wrong offset -- it should be returning 
240.. or 4 hours offset during DST, and not 300 or 5 hours (which would be 
correct in non-DST).

Opera and IE (hiss) both return 240.

Reproducible: Always

Steps to Reproduce:
1. offset = getTimezoneOffset();
2. window.alert(offset);
Actual Results:  
300

Expected Results:  
240

Comment 1

[Justin Matlock]

Bleh.. helps to be using the right browser during reporting so the build comes
up right. 

The build with the problem is:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910

Comment 2

[Boris Zbarsky [:bzbarsky]]

Hmm... So when I try this on my machine (I'm in the Central timezone and my
timezone is currently "PDT") I get "300".  Which is correct in my case...

Comment 3

[Phil Schwartau]

This also WORKSFORME using recent Mozilla trunk binaries on WinNT, WinXP.
If I set my Windows TimeZone to (GMT-05:00) Eastern Time (U.S. & Canada):

  javascript:alert(new Date().getTimezoneOffset()) ---> 240, not 300.


IDEA #1
Justin: what happens if you:

1. Open up your Windows Date/Time control panel
2. Look at the Time Zone tab
3. Look at the option "Automatically adjust clock for daylight saving changes"

Do you have this checked? Be sure to restart Mozilla each time you
change this, because it is only detected when the browser initializes.
If I uncheck this option and restart Mozilla, I see what you report:

  javascript:alert(new Date().getTimezoneOffset()) ---> 300


I'm not sure if this is the problem, however. Because then why would
Justin's Opera and IE browsers be working correctly, and Mozilla not?


IDEA #2
Justin: is your Windows TimeZone tab set to 

            (GMT-05:00) Eastern Time (U.S. & Canada)
        or  (GMT-05:00) something else?

Comment 4

[Phil Schwartau]

Reassigning -

Comment 5

[Justin Matlock]

I have verified the timezone information on my machine; I've even gone as far 
as to change my timezone, reboot, change it back to "(GMT-05:00) Eastern Time 
(US & Canada), (with the Adjust clock checked), and rebooted again.  Same 
results (300 instead of 240).

I'm running Win XP Pro, SP1.

Arg. I know this is starting to sound crazy.  I am still getting 300 back 
instead of 240.

I'm running "javascript:window.alert(new Date().getTimezoneOffset())" to get 
this.

Comment 6

[Justin Matlock]

I just uninstalled Mozilla, and scanned for and cleared out any mozilla 
registry entries.

I then rebooted, then redownloaded and reinstalled 1.2a from mozilla.org.

Now I'm getting 240, consistently.

I havent't touched my timezone settings since the install of the OS, although I 
did check them to make sure that was configured properly when I first ran into 
this problem.

Here's the kicker... I was telling a co-worker about the problem I was having. 
he was getting 240 on his 1.2a installation of Mozilla. However, he then 
installed the XP SP1 service pack, his started returning 300.  After an 
uninstall, reboot, then reinstall of Mozilla, he received 240 again.

Go figure.  I'm going to see if I can find any other un-SP1'd XP machines here 
at the office and see if I can duplicate the issue again.

Comment 7

[Phil Schwartau]

Justin: thanks, this is extremely valuable information for us!!!
I will check the SP# on our WinXP machines, too -

Comment 8

[Phil Schwartau]

The WinXP machine I tested on had SP1, too. But I don't happen
to know the history of Mozilla installs on that box, which seems
to be playing a role here -

Comment 9

[Phil Schwartau]

cc'ing dveditz in case this resembles other installation issues
that occur after Windows Service Packs are downloaded by users -

Comment 10

[Brendan Eich [:brendan]]

Possible dup of bug 63720?  From [e-mail]'s post at
news://news.mozilla.org:119/ci6tfq$[e-mail] it seems that rogue
TZ setting can mess up Windows localtime.

/be

Comment 11

[dave]

(In reply to comment #10)
> Possible dup of bug 63720?  From [e-mail]'s post at
> news://news.mozilla.org:119/ci6tfq$[e-mail] it seems that rogue
> TZ setting can mess up Windows localtime.

I have no idea to which among the various reported date/time/timezone bugs that
this is most applicable, but I just experienced the same behavior that was
reported in Usenet message to which you refer.  I had set the environment
variable "TZ" on Windows XP (SP2) to influence the behavior of another program
that depended upon its presence.  However, that caused Mozilla to display the
date from all of my new mail messages as 4 hours later than the corresponding
local time.  I'm in Boston, so -0400 (EDT) became  +0000 (GMT/UTC).  I tested
the various Javascript time and date functions from Mozilla Javascript console,
which demonstrated the same problem. 

Removing the "TZ" environment variable resolved the problem, but it strikes me
as odd that a modern Windows application's time/date functions are vulnerable to
an environment variable string even in the presence of a correctly configured
system time.  The origin of this quirk may have its origin 

(The following Usenet post is referenced from the previous reply)

In netscape.public.mozilla.jseng, 

Rod Whiteley wrote:

> I looked at the source code and found a call to localtime() in the C
> runtime library. On MSDN I found that this has a quirk -- it is
> vulnerable to the TZ environment variable being wrongly set. Mine was.
> I removed the TZ variable completely and the times are now OK.

Comment 12

[dave]

(In reply to comment #11)

...

> an environment variable string even in the presence of a correctly configured
> system time.  The origin of this quirk may have its origin 

That last sentence was supposed to read: "The origin of this quirk may be in the
C runtime library [on Windows]."

Dave

Comment 13

[timeless]

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_time_management.asp

Run-Time Library Reference 	 
Time Management

Use these functions to get the current time and convert, adjust, and store it as
necessary. The current time is the system time.

The _ftime and localtime routines use the TZ environment variable. If TZ is not
set, the run-time library attempts to use the time-zone information specified by
the operating system. If this information is unavailable, these functions use
the default value of PST8PDT. For more information on TZ, see _tzset; also see
_daylight, timezone, and _tzname.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_localtime.asp

localtime corrects for the local time zone if the user first sets the global
environment variable TZ. When TZ is set, three other environment variables
(_timezone, _daylight, and _tzname) are automatically set as well. If the TZ
variable is not set, localtime attempts to use the time zone information
specified in the Date/Time application in Control Panel. If this information
cannot be obtained, PST8PDT, which signifies the Pacific time zone, is used by
default. See _tzset for a description of these variables. TZ is a Microsoft
extension and not part of the ANSI standard definition of localtime.

i have no idea offhand how to deal with this. i'm fairly certain i'm the last
person to touch this code. you're welcome to make suggestions.

Comment 14

[Bob Clary [:bc] (inactive)]

-> default qa

Comment 15

[André Bargull [:anba]]

Unlikely to be still valid given that we're now using ICU an all platforms for time zone computations, therefore resolving as WFM.