TimeZone.getID() returns conflicting results

[Greg B]

Two machines in the same computer lab... both running Windows XP...
the only difference I see between them is that one of them is on the
domain, the other one isn't.

I installed Java SDK 1.4.3_03 on each machine, reboot, and then
compile a run the following two lines of code from within the 'main'
function of my sample class:

Calendar tmpCal = Calendar.getInstance();
System.out.println("Current timezone ID is: " +
tmpCal.getTimeZone().getID());


Interestingly enough, on the first machine (the one on the domain) the
output is
"Current timezone ID is: Australia/Melbourne", while on the other one
it is
"Current timezone ID is: GMT". This difference can (and does) cause
obvious problems... could someone please give me an idea as to why
this is happening?
I do not recall seeing any configuration options during Java SDK
installation which would allow me to configure the timezone settings.
As far as I can see, the Control Panel/Regional Settings and Control
Panel/Date and Time have identical values on both machines...

thanks in advance,

regards,
Greg

 

[Bryce (Work)]

I do not recall seeing any configuration options during Java SDK
installation which would allow me to configure the timezone settings.
As far as I can see, the Control Panel/Regional Settings and Control
Panel/Date and Time have identical values on both machines...

Check the Date and Time Properties.

Its up to the host to tell java what the time zone is.

In Windows XP, its

Control Panel -> Date and Time Properties. Time Zone tab.

 

[Roedy Green]

Two machines in the same computer lab... both running Windows XP...
the only difference I see between them is that one of them is on the
domain, the other one isn't.

go into the Windows control panel and see if their clocks and
timezones are set correctly. Then use an atomic clock to keep times
correct.

See http://mindprod.com/jgloss/atomicclock.html

 

[Roedy Green]

I installed Java SDK 1.4.3_03 on each machine, reboot, and then
compile a run the following two lines of code from within the 'main'
function of my sample class:

Run http://mindprod.com/wassup.html on both machines and look at the
timezone and locale related properties.

 

[Greg B]

go into the Windows control panel and see if their clocks and
timezones are set correctly. Then use an atomic clock to keep times
correct.

See http://mindprod.com/jgloss/atomicclock.html

Thanks for the feedback guys. Unfortunately, none of this seems to be
doing any good... but while going through some of the advice, I've
stumbled upon an help page which talks about synchronizing a computer
clock and how it is done differently if machine is a member of the
domain... will have a closer read of that now.

But yeah, the settings within Control Panel seem identical on both
machines, and even the Atomic Clock utility that I downloaded and
installed on both machines seem to be confirming that (there is a 1
hour difference in some of the times reported, but that still wouldn't
explain anything)

anyways, thanks again and I'll keep you updated on any findings

 

[Sudsy]

Greg B wrote:

But yeah, the settings within Control Panel seem identical on both
machines, and even the Atomic Clock utility that I downloaded and
installed on both machines seem to be confirming that (there is a 1
hour difference in some of the times reported, but that still wouldn't
explain anything)

It would explain everything! Think about it! If there's a difference
of one hour then the machines are obviously in different time zones.
One might be in DST while the other is not.
More likely, from the way you've described the problem, one of them
is in a timezone whose specification doesn't match anything in the
Java or standards database. So it defaults to GMT (or UTC).
Just a stab, but what's the ISO standard code for Australia/Central
time?

 

[Mark Thornton]

Two machines in the same computer lab... both running Windows XP...
the only difference I see between them is that one of them is on the
domain, the other one isn't.

I installed Java SDK 1.4.3_03 on each machine, reboot, and then
compile a run the following two lines of code from within the 'main'
function of my sample class:

Calendar tmpCal = Calendar.getInstance();
System.out.println("Current timezone ID is: " +
tmpCal.getTimeZone().getID());


Interestingly enough, on the first machine (the one on the domain) the
output is
"Current timezone ID is: Australia/Melbourne", while on the other one
it is
"Current timezone ID is: GMT". This difference can (and does) cause
obvious problems... could someone please give me an idea as to why
this is happening?
I do not recall seeing any configuration options during Java SDK
installation which would allow me to configure the timezone settings.
As far as I can see, the Control Panel/Regional Settings and Control
Panel/Date and Time have identical values on both machines...

thanks in advance,

regards,
Greg

It might be related to this bug

http://developer.java.sun.com/developer/bugParade/bugs/4891531.html

As well as the users locale on each machine have a look at the system
default locale.

Mark Thornton

 

[Roedy Green]

It might be related to this bug

http://developer.java.sun.com/developer/bugParade/bugs/4891531.html

in a pinch you can force the timezone to use with a -D system
property.

See http://mindprod.com/jgloss/timezone.html

 

[Greg B]

It might be related to this bug

http://developer.java.sun.com/developer/bugParade/bugs/4891531.html

As well as the users locale on each machine have a look at the system
default locale.

Mark Thornton

Prior to starting this thread, I've set the user's locale and system
default local to be "English (Australia)", then uninstalled and
re-installed Java SDK but still got the same problem when
TimeZone.getDefault().getID() was used...

also, the link you've provided seems to talk about difference in
output between "java" and "javaw" with the latter being the offender,
but in my case I just use "javac" followed by "java" from the command
line...

 

[Greg B]

Greg B wrote:


It would explain everything! Think about it! If there's a difference
of one hour then the machines are obviously in different time zones.
One might be in DST while the other is not.
More likely, from the way you've described the problem, one of them
is in a timezone whose specification doesn't match anything in the
Java or standards database. So it defaults to GMT (or UTC).
Just a stab, but what's the ISO standard code for Australia/Central
time?

If machines were obviously in different time zones, the atomic clock
utility would surely in its 'Standard Time Zone Name' and 'Daylight
Time Zone Name' display different timezone identifiers... but it
doesn't (shows AUS Eastern Standard Time and AUS Easter Daylight Time
respectively). Besides, if you forget about Java altogether, how many
different ways of specifying a timezone for a given machine can you
think of? Me, just one... by double-clicking on the clock in the tray
menu and then going to 'Time Zone' tab...

 

[Greg B]

Two machines in the same computer lab... both running Windows XP...
the only difference I see between them is that one of them is on the
domain, the other one isn't.

I installed Java SDK 1.4.3_03 on each machine, reboot, and then
compile a run the following two lines of code from within the 'main'
function of my sample class:

Calendar tmpCal = Calendar.getInstance();
System.out.println("Current timezone ID is: " +
tmpCal.getTimeZone().getID());


Interestingly enough, on the first machine (the one on the domain) the
output is
"Current timezone ID is: Australia/Melbourne", while on the other one
it is
"Current timezone ID is: GMT". This difference can (and does) cause
obvious problems... could someone please give me an idea as to why
this is happening?
I do not recall seeing any configuration options during Java SDK
installation which would allow me to configure the timezone settings.
As far as I can see, the Control Panel/Regional Settings and Control
Panel/Date and Time have identical values on both machines...

thanks in advance,

regards,
Greg

Well, after all of this pain, it turns out the problem was caused by
something than Java... one of the machines in question was using Ghost
image of Windows XP, which (I'm guessing) was created when certain
daylight savings mode was in effect. Possibly because that mode was
different to that in effect today, when the machine was 'ghosted' to
the XP image and Java was installed, there was some internal mismatch
in the system time data (hence the 1 hour difference in time reported
by the atomic clock utility), and Java defaulted to using 'GMT'...

If, right after 'ghosting' the machine, I was to switch to using
another timezone, and then switch back to using the correct one...
both the atomic clock utility, and the re-installed Java SDK correctly
reported the default timezone to be "Australia/Sydney"

Eek, speaking of weird problems. Thanks for all your feedback guys,
appreciate it

 

[Sudsy]

Greg B wrote:

Eek, speaking of weird problems. Thanks for all your feedback guys,
appreciate it

Eeks indeed! At least now you know that it wasn't a Java problem...
Nice to hear that you worked it out. One to put down in your bound
notebook, I daresay.