Closed Bug 309392 Opened 15 years ago Closed 3 months ago

(new Date(1174721282281)).getTimezoneOffset() is broken on Mac

Categories

(Core :: JavaScript Engine, defect)

PowerPC
macOS
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1346211

People

(Reporter: bzbarsky, Unassigned)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file)

Blocks: 281889
Requesting blocking, pending confirmation that the problem exists.
Flags: blocking1.8b5?
I just corresponded by email with Celso about this -- somehow I missed out on
bug 281889.  Anyhoo, XP_MAC is dead, long live XP_UNIX + XP_MACOSX, eh?

/be
I cannot reproduce. Typing this into the URL bar:

javascript: alert(new Date().getTimezoneOffset())

gives me an alert that says "420"

Mac OS X 10.4.2, today's Firefox 1.5 branch build
In case I missed something, why is the OS for this bug Linux and hardware PC?
Because bugzilla picked it up from my UA.
OS: Linux → MacOS X
Hardware: PC → Macintosh
I get 420 for both Firefox 1.4 and 1.6a1 on the "pineapple" qa Mac OS X machine. WFM
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
So how come Celso was seeing this bug?  Do we know?
Flags: blocking1.8b5?
We are using both XP_UNIX and XP_MACOSX. We're seeing this problem in Acrobat
with the new engine. We're building in CW against the 10.3.0 sdk. For your build
that is working, what OSX version or SDK version is sm/mac built with? I'm
assuming it's grabing the mktime function from whatever is in /usr/sys in the
machine. 
I'm going to reopen this; given that this is a JS engine issue being observed
outside of Firefox/SeaMonkey, the fact that it works in those is rather immaterial.

Rerequesting blocking, based on that.
Status: RESOLVED → REOPENED
Flags: blocking1.8b5?
Resolution: WORKSFORME → ---
(In reply to comment #8)
> We are using both XP_UNIX and XP_MACOSX. We're seeing this problem in Acrobat
> with the new engine. We're building in CW against the 10.3.0 sdk. For your build
> that is working, what OSX version or SDK version is sm/mac built with? I'm
> assuming it's grabing the mktime function from whatever is in /usr/sys in the
> machine. 

Whoa, we stopped building in CodeWarrior a long time ago  :) My guess is that
your #defines don't match our build, or you are picking up different versions of
a library.
> we stopped building in CodeWarrior a long time ago

"We" being Gecko, or "We" being the standalone JS engine, which is what it
sounds like Celso is building (though correct me if I'm wrong).
We're not using CW to build the shell, but an Acrobat plugin where the engine is
embedded. We're moving from CW to x-code pretty soon. My hope is that the
problem will go away when using x-code.
If we're supporting CW builds of jsengine as a tier-1/2 platform, this maybe is
a blocker, but without that we're too late in the game.
Flags: blocking1.8b5? → blocking1.8b5-
Flags: testcase-
with builds from 20060408 for 1.0.x, 1.5.0, 2.0 and trunk using ecma/Date/15.9.5.10-1.js on 2006-04-06 23:13:11. Seems to require a time just before midnight?

win/linux

js>  (new Date(1174721282281))
Fri Mar 23 2007 23:28:02 GMT-0800 (PST)
js>  (new Date(1174721282281)).getTimezoneOffset()
480

macosx

js>  (new Date(1174721282281))
Sat Mar 24 2007 00:28:02 GMT-0700 (PDT)
js>  (new Date(1174721282281)).getTimezoneOffset()
420

Flags: in-testsuite- → in-testsuite+
Summary: Date().getTimezoneOffset() is claimed to be broken on Mac → (new Date(1174721282281)).getTimezoneOffset() is broken on Mac
Blocks: 332722
Does anyone care that this is a mochitest? It seems more suited to xpcshell, but my build is having problems with xpcshell right now.

Do we have any preference on whether this is checked in as an xpcshell test or a mochitest? If we are ok with a mochitest, here you are.
It should be a js test. It should be added to the js test library when (if) it is ever fixed.
So, the js test suite does not have the equivalent of a "todo"? It actually seems useful to be able to check something in, say that it is going to work, and then, when the functionality it is testing is changed, the test pops up again and there you are.

Less time searching through old bugs trying to find relevant resources....

Perhaps the test can be checked in to the js harness and it can do the platform check, and if it is a mac, confirm the error condition. Sort of a todo() just for this test.
(In reply to comment #17)

not yet. I just prefer not to have to wade through lots of failures at the moment. I do need a solution for handling known failures but haven't gotten around to a solution yet. I'll check out what mochitest does with regard to that, but that is not that high on my list of stuff to do atm.
Assignee: general → nobody
I am not sure it is the same issue, but the following code works fine on Safari(Mac), Chrome(Mac, Win) and Firefox(win), but fails on Firefox(Mac):

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

What I expect is that it will give me the current system timezone offset, and it does.  But on Firefox(Mac) it will give me the wrong value if I change the system timezone with the browser open, it will return a wrong offset.  If I then restart the browser, the value will be correct again until I change the system timezone again.
I'm also having this problem, as reported by Alexandre.
Blocks: 285663

Should be fixed through bug 1346211 when we moved to ICU for time zone computations.

(The issue in comment #19 is already tracked in other bugs.)

Status: REOPENED → RESOLVED
Closed: 15 years ago3 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1346211
You need to log in before you can comment on or make changes to this bug.