Java Calendar cannot handle DST correct?
Marcus
I am trying to get to grips with Java Calendar class (and the TimeZone
class). I have noted some very weird behaviour though:
Try the following:
1) Bring up the Date and Time Properties window in Windows XP and
select the timezone (GMT -03:00) Montevideo. Leave the DST box
unchecked, click Apply. Now run the application code seen at the
bottom of this post. Note in Java output how Java identifies the
timezone as "GMT-03:00" and also outputs the time as being the same as
the Windows OS time. Correct behaviour according to me!
2) Click to check the DST box and then click Apply. Now run the
application code seen at the bottom of this post again. Note in Java
output that Java identifies the timezone as "GMT" and also outputs the
time as being 3 hours more than it was when using DST. Java's time is
now not correlated with Windows time.
WHAT IS GOING ON HERE???
Montevideo has got +1 hour DST time, not 3 hours. And how can Java
identify it as GMT when it really should be GMT-3. Montevideo is not
the only timezone that is identified as "GMT" when DST is enabled. For
example also "(GMT+04:00) Baku" and "(GMT+02:00) Beirut" are also
identified as "GMT" when DST is enabled.
I am confused by Java time management to say the least. If anyone has
any idea of what is going on here I would really appreciate some help.
public class TimeTestMain {
public static void main(String[] args) {
test();
}
private static void test(){
Calendar cal = Calendar.getInstance();
TimeZone tz = cal.getTimeZone();
System.out.println("TimeZone info: " + tz);
System.out.println("time in " + tz.getDisplayName() + " is: " +
cal.getTime().toString());
}
Mayeul
> Hi
>
> I am trying to get to grips with Java Calendar class (and the TimeZone
> class). I have noted some very weird behaviour though:
I don't think the problem is with the Calendar class, which have worked
fine with every DST-enabled time zones I have had to use so far.
But it does seem to me that Java has issues with its way to handle time
zones at the core.
The way I see it, Java embeds its own time zone descriptions with the
base library, and uses these exclusively. It means to define a time
zone, it either defines it as GMT+x or GMT-x, either as a known time
zone like America/Los_Angeles, applying its official DST rules,
including historical changes.
Now what happens if the operating system is set to a time zone that
either is unknown, either operates with DST rules that are not the ones
Java acknowledges? Discrepancies, that's what. I would expect Java to
try and make a best effort to match the operating system's announced
time zone with something Java knows. It is bound to produce very
unexpected results at least sometimes.
I am sure there are upsides to this behavior, but not sure what they are
(aside from relatively consistent cross-platform behavior.)
It so happens I've only been inconvenienced by it by the fact that linux
distros rarely announce what time zone they're using, leading to
detection errors and forcing me to setup the system so that it does set
a TZ environment variable.
Aside from that, works fine for me and my clients.
--
Mayeul
Thomas Pornin
> The way I see it, Java embeds its own time zone descriptions with the
> base library, and uses these exclusively. It means to define a time
> zone, it either defines it as GMT+x or GMT-x, either as a known time
> zone like America/Los_Angeles, applying its official DST rules,
> including historical changes.
Yes: when starting, the JVM looks at the OS setting to deduce the "local
time zone" and then works on his own (i.e. Java will not talk to the OS
again to convert dates and times, it will just run on the DST rules
which apply to the inferred local time zone). There are many time zones
out there, and quite a few operating systems as well, which means a high
number of possible combinations; it can only be expected that some of
them were not fully tested.
Here, it seems probable that whatever "checking the DST box and cliking
'Apply'" does, did confuse the automatic detection from Java. It is
quite possible that Java knows of the proper time zone information, only
that it did not recognized the local time zone as what it is.
Note also that since Java runs on its own tables, it is important that
those tables are updated frequently. Uruguay changed its DST rules
2004. The neighbouring Argentina changed its DST rules less than
two years ago, effective only since last month. On my Linux system
(Ubuntu), Sun's JVM is handled by the system package manager, and the
time zone data is often updated, as the 'tzdata-java' package.
> It so happens I've only been inconvenienced by it by the fact that
> linux distros rarely announce what time zone they're using
Mine has a /etc/timezone file, filled with the time zone name. It
looks fairly common to me.
Many discrepancies arise from dual-boot systems, with a Linux and a
Windows. Windows wants to keep the CMOS clock (the one which is
battery-powered) in local time, adjusting it for DST twice a year. Linux
systems are usually much happier when the CMOS clock is in UTC. On a
dual boot system, this cannot work properly; there are several
workarounds, some being plainly wrong but apparently correct (e.g.
setting the Linux system's /etc/timezone to "GMT", so that displayed
time appears to match local time -- as long as one ignores the time zone
indication).
--Thomas Pornin
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>Now what happens if the operating system is set to a time zone that
>either is unknown, either operates with DST rules that are not the ones
>Java acknowledges? Discrepancies, that's what. I would expect Java to
>try and make a best effort to match the operating system's announced
>time zone with something Java knows. It is bound to produce very
>unexpected results at least sometimes.
You can force the timezone with a System property. You can check what
it is using with Wassup or with the TZ applet. see
http://mindprod.com/applet/wassup.html
http://mindprod.com/jgloss/tz.html
For background info on timezones and DST, see
http://mindprod.com/jgloss/timezone.html
http://mindprod.com/jgloss/dst.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
Without deviation from the norm, progress is not possible.
~ Frank Zappa (born: 1940-12-21 died: 1993-12-04 at age: 52)
Roedy Green
powers. Terrorists have no particular power individually, only in
their ability to convince and co-ordinate others. In prison, they
don't have that power.
If there is any danger, it comes from those NOT incarcerated.
Mayeul
> According to Mayeul <mayeul....@free.fr>:
>> It so happens I've only been inconvenienced by it by the fact that
>> linux distros rarely announce what time zone they're using
>
> Mine has a /etc/timezone file, filled with the time zone name. It
> looks fairly common to me.
Well, yes. I shouldn't have written "rarely announce." Its more like
distro commonly do not announce the time zone they're using in
cross-distro consistent way.
/etc/timezone is fairly common and fairly commonly absent. More to the
point, it does not seem very recognized as the (an) official way to
announce system's time zone, and last time I checked Java ignored it
(then again, it was probably in 2007.)
Besides, system time zone fails to handle the case when a server is used
for remote access by people in different time zones. Granted, it might
not be the most common use case, but come on, it /should/ work easily :).
This is why I prefer the TZ variable method for now. It is recognized by
most programs, and may be set on a per-user basis. There is the
occasional clash with desktop environments' clock setting utilities but
it is rarely an inconvenience.
> Many discrepancies arise from dual-boot systems, with a Linux and a
> Windows. Windows wants to keep the CMOS clock (the one which is
> battery-powered) in local time, adjusting it for DST twice a year. Linux
> systems are usually much happier when the CMOS clock is in UTC. On a
> dual boot system, this cannot work properly; there are several
> workarounds, some being plainly wrong but apparently correct (e.g.
> setting the Linux system's /etc/timezone to "GMT", so that displayed
> time appears to match local time -- as long as one ignores the time zone
> indication).
Yes, I've noticed there are issues in this regard, but I came to expect
them as a Windows limitation. I'm speaking about freenux-only boxes,
with system clock as GMT.
--
Mayeul
Roedy Green
quoted or indirectly quoted someone who said :
>Many discrepancies arise from dual-boot systems, with a Linux and a
>Windows. Windows wants to keep the CMOS clock (the one which is
>battery-powered) in local time, adjusting it for DST twice a year. Linux
>systems are usually much happier when the CMOS clock is in UTC. On a
>dual boot system, this cannot work properly; there are several
>workarounds, some being plainly wrong but apparently correct (e.g.
>setting the Linux system's /etc/timezone to "GMT", so that displayed
>time appears to match local time -- as long as one ignores the time zone
>indication).
for a windows fix, see http://mindprod.com/jgloss/clock.html
Lew
> I have to laugh at American fearing the accused, as if they had super
> powers. Terrorists have no particular power individually, only in
> their ability to convince and co-ordinate others. In prison, they
> don't have that power.
>
> If there is any danger, it comes from those NOT incarcerated.
>
Two years ago I bought a car that has a sunroof ...
--
L:ew
Eric Sosman
> I have to laugh at American fearing the accused, as if they had super
> powers. Terrorists have no particular power individually, only in
> their ability to convince and co-ordinate others. In prison, they
> don't have that power.
>
> If there is any danger, it comes from those NOT incarcerated.
The danger is that their lawyers might be able to force the
courts to change the daylight saving time rules yet again, and
thus inflict untold economic disruption.
(Well, that's the only reason I can imagine for raising this
topic in this thread.)
--
Eric Sosman
eso...@ieee-dot-org.invalid
Teraposa Lunodas
Marcus
> Note also that since Java runs on its own tables, it is important that
> those tables are updated frequently. Uruguay changed itsDSTrules
> two years ago, effective only since last month. On my Linux system
> (Ubuntu), Sun's JVM is handled by the system package manager, and the
> time zone data is often updated, as the 'tzdata-java' package.
Thanks for answering everyone, but I do not have old Java tables since
I use the very latest release of Java (Sun).
I also do NOT believe that Montevideo, Beirut and Baku all have had
their amount of DST hours changed so that they enter GMT when they are
in DST.
The regular Windows user (Windows is all that matters in my case) sets
his geographic position in the world by using Windows built-in tools
like the "Date and Time Properties" window that appears when double
clicking on the clock in the icon tray.
I can not get all our customers around the world to use some third
party application to set their timezone because Java is not compliant.
If I have misunderstood some obvious explanation to my problem in a
previous post, then I am sorry and hope you will explain it in easier
terms for a dummy like me. But to me it still seems like a definitive
shortcoming of Java. Surely Java should be able to correlate its time
with the worlds far most popular operating system without the use of
some 3rd party tools?
Marcus
Well since no one seems to know how to solve this the "Java" way, I
will just briefly explain my final solution for this, in case of
anyone else wondering.
I avoided Java built in classes like Calendar and Date as much as
possible and instead I made my own class that retirieves the date and
time from Windows environment variables named "date" and "time".
This date/time is always 100% correlated with Windows time (of
course).
To be able to know if the local computer is in DST, my class compares
the registry keys "ActiveTimeBias" and "Bias" (both of which are found
in HKLM/SYSTEM/CurrentControlSet/Control/TimeZoneInformation)
/Marcus