See bug 281889 comment 31.

Requesting blocking, pending confirmation that the problem exists.

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.

I get 420 for both Firefox 1.4 and 1.6a1 on the "pineapple" qa Mac OS X machine. WFM

So how come Celso was seeing this bug? Do we know?

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.

(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.

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

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.

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.