This content has been marked as final. Show 49 replies
So obviously something is different on that machine versus the others. Yet you claim they're all the same. So now, do we attempt to look at the odd box via osmosis, or what?
You can never trust what goes on in Tijuana...
All machines are running java 1.4.2_03 on WinXP SP1 with all latest updates as of 5/25/04.Except the bad machine, I suspect. What does
It is the same java version on all machines.
$ java -version java version "1.4.2_03" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02) Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)
And the test cases you showed, they were all produced by typing "java something" at the command line?
You can never trust what goes on in Tijuana...I don't know whether bsampieri was kidding, but he gave you the answer. Check that the "bad" machine's timezone is also Los Angeles and not Tijuana (even though both are GMT-8).
I will look up a reference for you regarding why Tijuana is broken.
I will look up a reference for you regarding why Tijuana is broken.Cancel that, it doesn't even apply to XP. :-(
Cancel that, it doesn't even apply to XP. :-(Nonetheless, for lack of better ideas check whether the following registry section differs between machines
Actually, I was kidding... however, it got me wondering... maybe Tijuana, according to Java, does not use Daylight Savings Time? ... It's supposed to... nah, that's probably not it...
If Java is reading the timezone as GMT-8, it's not going to use DST. It needs a specific zone ID, because not every place uses DST in the physical area of the zone.
You can set the default time zone via a parameter on the command-line... I forget the name of it, though.
To reiterate, all machines are set to the same timezone in the Windows Date&Time control panel. In that control panel, on all machines, the only option for Pacific Time is "(GMT-0:800) Pacific Time (US & Canada); Tijuana".
The "Tijuana" is a windows thing. "America/LosAngeles" is Java's iterpretation of that Windows setting, at least when Java & Windows are working correctly together.
I've been looking at the java source to see how they get the time zone from Windows. The source that comes with the JDK ends up (of course) calling a native method getSystemTimeZoneID(). I've downloaded the SCSL source to see what that native method is doing. It ends up looking at the registry key SYSTEM\\ControlSet001\\Control\\TimeZoneInformation (or System\\CurrentControlSet\\Control\\TimeZoneInformation) to see what time zone Windows thinks it is in. Those registry keys are identical on the two machines. So, I'm still stumped.
And to reply to an earlier question, the test cases were all from typing "java Test" on the command line. Although that doesn't seem to matter - the problem most noticably shows up in all the logfile entries that we are writing from our app in Tomcat, and in the fact that timestamps on rows inserted into mysql are an hour off from when java thinks it put them in. Java is an hour behind all the other s/w running on the machine (mysql, Apache, Windows).
Also, searching for the write-up on that PST/Tijuana problem I hit the following item. Check the section titled "Platform Time Zone Detection on Microsoft Windows".
The way I read it that "global system setting" thing is buggy and is not necessarily in step with what you see on the Control Panel. The described symptoms match what you're seeing.
The documented case doesn't match your situation exactly, but do try changing the time zone to something else and back again.
Tried setting timezone to Tokyo (which does not observer daylight savings time), then back to Pacific. Problem still present. Tried setting to Mountian time zine (which does observer daylight saving) and back - problem still present.
One interesting thing: on the "bad" machine, java always shows the timezone in the generic GMT +/- offset format. On a good machine, java is able to translate into the "America/Los_Angeles" format. Just to check, I explicly set the timezone on the bad machine (with
and then the bad machine does display the correct time and timezone.
So, somehow it is not able to use what it gets back from Windows to correctly look up the "America/Los_Angeles" style timezone, so it falls back to the GMT+-offset format.
I verified that the java installations are identical on all machines (I zipped up the one on the bad machine, and did a file-by-file byte compare to one on a good machine).
Any idea what the global system setting "Automatically adjust clock for daylight saving changes." is? Is that what gets set when one checks the box in the Date/Time control panel? And, what is the registry key for it? I'll investigate those....