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

VERIFIED FIXED in mozilla1.9.2a1

Status

()

defect
--
major
VERIFIED FIXED
12 years ago
3 years ago

People

(Reporter: frankmanno, Assigned: crowderbt)

Tracking

({fixed1.9.1})

Trunk
mozilla1.9.2a1
PowerPC
macOS
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.1 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [needs test?] [needs rollup patch for 1.9.0])

Attachments

(2 attachments, 3 obsolete attachments)

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)
- Note: Firefox 2.x/Win does not suffer from this problem.
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.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Marcia, does Safari show the same behavior?
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 */
Safari is using CFDateFormatter for this...  I'll investigate more.
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.
Assignee: general → crowder
Status: NEW → ASSIGNED
Also, it must be a data-bug in Mac OS X's POSIX time tables that the extra half-hour isn't observed.
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.
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.
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).
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.
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
The patch in bug 445879 fixes the bogus math!
Depends on: 445879
No longer depends on: 445879
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.
Attachment #296678 - Flags: review?(mrbkap)
Depends on: 445879
Attachment #296678 - Flags: review?(mrbkap) → review+
Duplicate of this bug: 318454
Looks like I was on crack in comment #13, though.  Need more thought on the bogus math issue.
Posted patch v2 (obsolete) — Splinter Review
This actually fixes the math AND the WILDABBR bug
Attachment #296678 - Attachment is obsolete: true
Attachment #343063 - Flags: review?(mrbkap)
Attachment #343063 - Flags: review?(mrbkap) → review+
Keywords: checkin-needed
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!
changeset:   20488:82af7163534f

We should be able to test this by running the date tests with TZ="America/Caracas"
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite?
Keywords: checkin-needed
Resolution: --- → FIXED
Have to massage this through the try server a few times.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
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.
Posted patch v3 (obsolete) — Splinter Review
This one survives a Try build.
Attachment #343063 - Attachment is obsolete: true
Attachment #343439 - Flags: review?(mrbkap)
Attachment #343439 - Attachment is patch: true
Attachment #343439 - Attachment mime type: application/octet-stream → text/plain
Attachment #343439 - Flags: review?(mrbkap) → review+
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.
crowder, is this something we could possibly get for 3.1?
Flags: wanted1.9.1?
Yes, it is something we likely -should- get in as soon as reasonable, I wish I hadn't lost track of it before b2.
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!
Crowder, any update here? It would be nice to get this in for b3.
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.
Attachment #343439 - Attachment is obsolete: true
Attachment #355421 - Flags: review+
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..
http://hg.mozilla.org/mozilla-central/rev/d2b395fc397e
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
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
Attachment #355421 - Flags: approval1.9.1?
Attachment #355421 - Flags: approval1.9.0.7?
(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?
Flags: wanted1.9.1? → wanted1.9.1+
Attachment #355421 - Flags: approval1.9.1? → approval1.9.1+
Other than a potential perf-hit for code doing a lot of time-formatting, I don't think the risk here is very great.
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?
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?
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
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!
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.
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.
Blocks: 449757
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
We're not backing the patch out, so please file a separate bug for the Solaris porting problem. Thanks,

/be
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Blocks: 472622
No longer blocks: 449757
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.
Whiteboard: [needs test?][needs bug 472622 fixed]
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.
It doesn't need to be cross platform necessarily... We can do platform-specific tests.
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?
No longer blocks: 472622
Depends on: 472622
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
Attachment #355421 - Flags: approval1.9.0.7? → approval1.9.0.7-
Whiteboard: [needs test?][needs bug 472622 fixed] → [needs test?][needs rollup patch for 1.9.0]
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.
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)
Status: RESOLVED → VERIFIED
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.  :(
Depends on: 485013
Whiteboard: [needs test?][needs rollup patch for 1.9.0] → [needs 1.9.1 landing] [needs test?] [needs rollup patch for 1.9.0]
Target Milestone: --- → mozilla1.9.2a1
Version: unspecified → Trunk
Comment on attachment 355421 [details] [diff] [review]
Update for the autoconf world (the one to land)

1.9.1 rollup coming right up.
Attachment #355421 - Flags: approval1.9.1+
Posted patch roll-upSplinter Review
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
Attachment #372086 - Flags: approval1.9.1?
Comment on attachment 372086 [details] [diff] [review]
roll-up

a191=beltzner
Attachment #372086 - Flags: approval1.9.1? → approval1.9.1+
Also, if the test could get completed, that'd be nice :)
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/eb3206d9774e
Keywords: fixed1.9.1
Whiteboard: [needs 1.9.1 landing] [needs test?] [needs rollup patch for 1.9.0] → [needs test?] [needs rollup patch for 1.9.0]
Afaik, the current js/src testing infrastructure doesn't include any way to set the machine's timezone...  is there some better approach?
I'm sorry about my question but... how do I apply this patch ?
(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.
Duplicate of this bug: 479027
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?
CORRECTION:

***Firefox 50.1.0
You need to log in before you can comment on or make changes to this bug.