411726 - Date's time zone is incorrect when machine time zone is set to Caracas (Venezuela) on OS X

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Frank Manno]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

On OS X, when the machine's time zone is set to Caracas - Venezuela, the JavaScript Date object returns an incorrect Date instance.  

This is reproducible on Firefox/Mac (2.x, 3.xb) and SeaMonkey/Mac (Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008011001 SeaMonkey/2.0a1pre).  Safari also exhibits this behaviour, whereas Opera 9.5b does not.

Reproducible: Always

Steps to Reproduce:
Steps to reproduce:

1) Set machine's time zone to Caracas - Venezuela (VET)
2) create a new Date object: new Date();
3) Date displayed is incorrect; shows an offset of -1830 and the time zone is set as (WILDABBR)

example:

>> new Date();
> Fri Jan 11 2008 15:05:10 GMT+1930 (WILDABBR)
Actual Results:  
The following Date object is returned:

Fri Jan 11 2008 15:05:10 GMT+1930 (WILDABBR)


Expected Results:  
Thu Jan 10 2008 15:05:10 GMT-430 (VET)

Comment 1

[Frank Manno]

- Note: Firefox 2.x/Win does not suffer from this problem.

Comment 2

[Marcia Knous [:marcia]]

Confirmed using Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008011004 Minefield/3.0b3pre, although not just confined to VET. I chose Georgetown - Guyana and got similar output to what the reporter lists, Fri Jan 11 2008 19:39:38 GMT+2000 (WILDABBR). If I switch to VET I see the same thing he does.

Comment 3

[Bob Clary [:bc] (inactive)]

Marcia, does Safari show the same behavior?

Comment 4

[Bob Clary [:bc] (inactive)]

Safari 3.0.4 on Mac OS X 10.4.11 ppc does not show WILDABBR. Also I don't see this on Linux, so Mac only.

It appears to be abuse of localtime.c

#ifndef WILDABBR
/*
** Someone might make incorrect use of a time zone abbreviation:
**	1.	They might reference tzname[0] before calling tzset (explicitly
**		or implicitly).
**	2.	They might reference tzname[1] before calling tzset (explicitly
**		or implicitly).
**	3.	They might reference tzname[1] after setting to a time zone
**		in which Daylight Saving Time is never observed.
**	4.	They might reference tzname[0] after setting to a time zone
**		in which Standard Time is never observed.
**	5.	They might reference tm.TM_ZONE after calling offtime.
** What's best to do in the above cases is open to debate;
** for now, we just set things up so that in any of the five cases
** WILDABBR is used.  Another possibility:  initialize tzname[0] to the
** string "tzname[0] used before set", and similarly for the other cases.
** And another:  initialize tzname[0] to "ERA", with an explanation in the
** manual page of what this "time zone abbreviation" means (doing this so
** that tzname[0] has the "normal" length of three characters).
*/
#define WILDABBR	"   "
#endif /* !defined WILDABBR */

Comment 5

[Brian Crowder]

Safari is using CFDateFormatter for this...  I'll investigate more.

Comment 6

[Brian Crowder]

Attachment: fill in NULL'd out members of struct tm before calling strftime

So.  I have fixed the VET part, the GMT offset is a little weirder.  Here's what python says:

>>> time.strftime("%z")
'-0400'

(ie: missing the half-hour)

Here's what we do, still:

js> new Date()     
Sun Jan 13 2008 03:49:42 GMT+1930 (VET)


I need to spend more time debugging the bogus math.

Comment 7

[Brian Crowder]

Also, it must be a data-bug in Mac OS X's POSIX time tables that the extra half-hour isn't observed.

Comment 8

[Frank Manno]

Brian,

I've checked to see whether or not OS X is observing the extra 1/2 hour, and it seems as though it does indeed behave properly.

Not sure if that's what you're looking for; this was done in the "Date/Time" system preference pane.

Comment 9

[Brian Crowder]

Frank:  I'm talking about the values returned by the POSIX date/time routines, not those maintained by the OS, or those used by the non-POSIX date/time routines.

Comment 10

[Brandon]

I first posted this comment under bug 318454, but that is an "old unconfirmed bug" so I'm repeating myself here.

I have this problem on Arch Linux with firefox (bon echo) version 2.0.0.12. I
built my own copy of version 3 beta 3 and still have the problem.
javascript:alert(new Date()) reports GMT+1500 (AKDT) when the Alaska Daylight
time (AKDT) should be GMT-0800 and the current time, Alaska Standard time
(AKST), should be GMT-0900.

My locale is set to en_US.utf8, my hardware clock uses UTC and my timezone is
set to America/Juneau. I use glibc version 2.7 and /bin/date reports the time
correctly, as do other applications (which I assume use the POSIX date/time routines).

Comment 11

[Patrick O'Callaghan]

This bug exists in FF 3b5 under Fedora 8. The timezone reported by Javascript for Venezuela is GMT+1930 instead of GMT-0430. In 24-hour modular arithmetic they give the same time of day, but the date is usually off by one.

Konqueror 3.5.9 and FF 2 on the same machine both get it right so it's not a system issue.

Comment 12

[Carlos Villaronga]

I have the same problem,The Timezone reported by Javascript for Venezuela (VET) is GMT+1930 instead of GMT-0430 am using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13) Gecko/20080325 Ubuntu/7.10 (gutsy) Firefox/2.0.0.13

Comment 13

[Brian Crowder]

The patch in bug 445879 fixes the bogus math!

Comment 14

[Brian Crowder]

Comment on attachment 296678 [details] [diff] [review]
fill in NULL'd out members of struct tm before calling strftime

Still want the original patch I wrote here, for Darwin.

Comment 16

[Brian Crowder]

Looks like I was on crack in comment #13, though.  Need more thought on the bogus math issue.

Comment 17

[Brian Crowder]

Attachment: v2

This actually fixes the math AND the WILDABBR bug

Comment 18

[Robert Koch]

This error returns with some update in firefox 3. I added information in BUG 318454 (now duplicated)

I reproduce the error with these steps:

1.
Create a HTML file
<!-- bad_date.html --> 
<html>
<head>
        <title>Date Problem</title>
</head>
<body>
<script language="JavaScript">
document.write(new Date())
</script>
</body>
</html>

2.
Open it with Mozilla Firefox

3.
See the results

Actual Results:  
Wed Oct 15 2008 16:09:05 GMT+1930 (VET) 

Expected Results:  
Wed Oct 15 2008 16:09:05 GMT-0430 (VET) 


The About says:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3) Gecko/2008092510 Ubuntu/8.04 (hardy) Firefox/3.0.3

I Hope this helps!

Comment 19

[Brian Crowder]

changeset:   20488:82af7163534f

We should be able to test this by running the date tests with TZ="America/Caracas"

Comment 20

[Brian Crowder]

Have to massage this through the try server a few times.

Comment 21

[mitsurugi]

I have the same problem using Firefox 3.0.2

In the about box there's the following info:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.2) Gecko/2008092318
Fedora/3.0.2-1.fc9 Firefox/3.0.2

The point is that _maybe_ this issue has something to do with thunderbird also. There's a bug that appears on thunderbird that the calendar displays tomorrow's date instead of today's date.

Hope you guys can solve it.

Comment 22

[Brian Crowder]

The attachment called "v2" has the solution, I just need to fix the build-breakage it introduces.  Thank you for the helpful ideas, but we've got a good handle on this now, I think.

Comment 23

[Brian Crowder]

Attachment: v3

This one survives a Try build.

Comment 24

[Juan Escajadillo]

I have this problem too. I knew this happens not only in Linux, but also in Macs. What you describe here is exactly the same problem. I need a patch badly for my Firefox.

Comment 25

[Bob Clary [:bc] (inactive)]

crowder, is this something we could possibly get for 3.1?

Comment 26

[Brian Crowder]

Yes, it is something we likely -should- get in as soon as reasonable, I wish I hadn't lost track of it before b2.

Comment 27

[Luis Daniel Ibáñez]

Hi Brian, any progress in this? or at least an instruction to apply the patch?

The impact that this haves in gmail is killing me, i already noticed it in debian and ubuntu firefox-iceweasel installs.

Besides changing my timezone to Aruba (and deal with only half hour of bogus), i haven`t found a decent workaround.

Thanks in advance!

Comment 28

[Robert Sayre]

Crowder, any update here? It would be nice to get this in for b3.

Comment 29

[Brian Crowder]

Attachment: Update for the autoconf world (the one to land)

The old version of this patch had fixups for the config/Darwin.mk file, which no longer exists.  The new version relies on configure.  No code in .cpp/.h files changed, and I've got r+ from ted on IRC for the configure.in tweak I've made both here and at the top-level.

Comment 30

[Jose Rafael Rojas]

Hi Brian,

I also got crazy with this bug.. i use several web apps (like Remember The Milk) that works bad for this reason (my tasks are always in the future).. 

This last patch fixes the bug? How could i help?

This bug has several months unresolved and too many people in Venezuela is leaving Firefox to use Opera (that haven't this bug)..

Please help us..

Comment 31

[Brian Crowder]

http://hg.mozilla.org/mozilla-central/rev/d2b395fc397e

Comment 32

[Brendan Eich [:brendan]]

Comment on attachment 355421 [details] [diff] [review]
Update for the autoconf world (the one to land)

We should fix for 1.9.1 -- please self-nominate patches for approval in non-blocking bugs (though this bug could be a blocker, maybe).

Should we get this into 3.0.x too?

/be

Comment 33

[Robert Sayre]

(In reply to comment #32)
> 
> Should we get this into 3.0.x too?

I think we should try. Can crowder/mrbkap give a risk assessment here?

Comment 34

[Brian Crowder]

Other than a potential perf-hit for code doing a lot of time-formatting, I don't think the risk here is very great.

Comment 35

[Luis Daniel Ibáñez]

Brendan, i assume that you speak of firefox when you talk of 3.0.x, but i don't catch the 1.9.1 , is nspr?

Comment 36

[Marcia Knous [:marcia]]

Luis: Brendan means the 1.9.1 branch, which is the in-development version of Firefox 3.1. The fix has been checked into the trunk per Comment 31.

(In reply to comment #35)
> Brendan, i assume that you speak of firefox when you talk of 3.0.x, but i don't
> catch the 1.9.1 , is nspr?

Comment 37

[Brendan Eich [:brendan]]

1.9.1 should be familiar from rv: user-agent sub-string:

rv:1.9.0.5

is in my 3.0.5 Firefox's javascript:navigator.userAgent output.

Mozilla milestones as separate source release targets are still numbered in bugzilla the same way. See the Target Milestone input.

Long time since Mozilla 1.0!

/be

Comment 38

[Luis Daniel Ibáñez]

Thanks Marcia!

Now, let me see if i understand well. If i want to check it i should use the
instructions here
https://developer.mozilla.org/en/Mozilla_Source_Code_(Mercurial)#mozilla-1.9.1_(Firefox_3.1)
right?

if it can be merged into 3.0.x, would be great, it will make faster the process
of the distros to include the change (particularly debian and ubuntu, which are
the most used here), José and I sure will go very quickly to the package
maintainers as soon as you finish it. 

Brendan: You are right, i should have noticed it. To be honest, i just use firefox (and very recently, thunderbird) from the mozilla suite. I'm really not as aware as i should about the mozilla releases (but im the most updated that i can in firefox :P).
 
Thanks for the good job guys!

Comment 39

[Luis Daniel Ibáñez]

Brendan, let me rephrase that last, adding that the fact is that i just follow the firefox release numbers, not the mozilla ones.
anyway, my bad.

Comment 40

[Ginn Chen]

Brian, it breaks Solaris build.

Should we add something like this around tm_gmtoff and tm_zone?

http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/misc/prtime.c#1720
1720 #if defined(SUNOS4) || (__GLIBC__ >= 2) || defined(XP_BEOS) \
1721         || defined(NETBSD) || defined(OPENBSD) || defined(FREEBSD) \
1722         || defined(DARWIN) || defined(SYMBIAN)
1723         a.tm_zone = NULL;
1724         a.tm_gmtoff = tm->tm_params.tp_gmt_offset +
1725                       tm->tm_params.tp_dst_offset;
1726 #endif

On SunOS 5.x, it doesn't have tm_gmtoff and tm_zone in std::tm.

Comment 41

[Brendan Eich [:brendan]]

We're not backing the patch out, so please file a separate bug for the Solaris porting problem. Thanks,

/be

Comment 42

[Samuel Sidler (old account; do not CC)]

I'm not sure I like taking this in 1.9.0 until we have an automated test for it. I also don't think we should break the Solaris build on the stable branch so we should get bug 472622 fixed and have a full roll up patch in this bug before taking it.

Comment 43

[Brian Crowder]

I'm not sure how to do a cross-platform automated test for this, since it could potentially require changing the system's timezone.  I'll gladly do a roll-up with the Solaris fix when we get it, though.

Comment 44

[Samuel Sidler (old account; do not CC)]

It doesn't need to be cross platform necessarily... We can do platform-specific tests.

Comment 45

[Brian Crowder]

Sorry, disregard comment #43.  We just need to set TZ, as I suggested in comment #19.  I think that needs to happen before the JS library is initiated, though.  How can we integrate that with jsDriver?

Comment 46

[Daniel Veditz [:dveditz]]

Comment on attachment 355421 [details] [diff] [review]
Update for the autoconf world (the one to land)

minusing to get a branch-merged patch that includes the regression fix from bug 472622

Comment 47

[Brian Crowder]

In truth, I'm not even sure if this is needed for 1.9.0.7, can someone check?  The patch that landed here is definitely not ready for that world, sorry for the spurious approval request.

Comment 48

[Bob Clary [:bc] (inactive)]

it is needed for 1.9.0 and 1.9.1. confirmed that it is ok for 1.9.2/mac os x/intel32.

$ echo $TZ
America/Caracas

new Date()
Thu Jan 29 2009 18:16:49 GMT-0430 (VET)

Comment 49

[Brian Crowder]

Oh, I was told sayrer would be landing 1.9.1 patches, perhaps I misunderstood...  Thought this was already good to go for 1.9.1.  :(

Comment 50

[Brian Crowder]

Comment on attachment 355421 [details] [diff] [review]
Update for the autoconf world (the one to land)

1.9.1 rollup coming right up.

Comment 51

[Brian Crowder]

Attachment: roll-up

This is the roll-up including the "update for autoconf world" patch from this bug, Ginn Chen's patch v4 for bug 472622, and "the fix" from bug 485013

Comment 52

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 372086 [details] [diff] [review]
roll-up

a191=beltzner

Comment 53

[Mike Beltzner [:beltzner, not reading bugmail]]

Also, if the test could get completed, that'd be nice :)

Comment 54

[Robert Sayre]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/eb3206d9774e

Comment 55

[Brian Crowder]

Afaik, the current js/src testing infrastructure doesn't include any way to set the machine's timezone...  is there some better approach?

Comment 56

[Robert Koch]

I'm sorry about my question but... how do I apply this patch ?

Comment 57

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #56)
> I'm sorry about my question but... how do I apply this patch ?

It's already landed for Firefox 3.5.x and above.

Comment 59

[Thomas Pessato]

Hey there. I'm using Firefox 50.0.1, on an iMac (OSX Yosemite).

If I leave firefox opened, change my system's timezone and then do this in the console:

var date = new Date();
date.getTimezoneOffset();

Most of the time it gives me the incorrect timezone.

Is this a new bug?

Comment 60

[Thomas Pessato]

CORRECTION:

***Firefox 50.1.0