Daylight savings problem

[Svante Nicholas Arvedahl]

Hi all!
I have the following problem with jdk 1.3.1 on Windows XP Home edition:

If I uncheck the box "Automatically adjust clock for daylight saving
changes" the time in my Java program is one hour ahead, as presented by
Date.toString for example, of the time presented in Windows XP. Further the
useDaylightSavings method of the default TimeZone (as returned by
TimeZone.getDefault()) always returns true, no matter if the win xp
"daylight saving" box is checked or not. I've tried setting XP up for both
the Stockholm time zone (gmt +1:00) and Central Time (GMT -6:00)

I have a simple test program:

Date date = new Date();
System.out.println(date);
System.out.println((TimeZone.getDefault().getDisplayName()));
System.out.println((java.util.TimeZone.getDefault().getRawOffset()));
System.out.println("Use dst: " +
java.util.TimeZone.getDefault().useDaylightTime());
System.out.println("In dst: " +
TimeZone.getDefault().inDaylightTime(date));

If I set xp up for central time 1:00 am and check the "daylight saving" box.
I get the following:
Mon Oct 20 01:00:25 CDT 2003
Central Standard Time
-21600000
Use dst: true
In dst: true

If I instead uncheck the "daylight saving" box and set the time to 1:00 am.
I get this:
Mon Oct 20 02:00:51 CDT 2003
Central Standard Time
-21600000
Use dst: true
In dst: true

I.e. one hour ahead and no way for me to compensate. Supplying a timezone at
the command line is not an option for me since I want my program to run
anywhere in the world with the time presented in the program in accordance
with the time presented in Windows.
Can anyone help me out on this one?

Thanks
Svante

 

[Paul Lutus]

Hi all!
I have the following problem with jdk 1.3.1 on Windows XP Home edition:

If I uncheck the box "Automatically adjust clock for daylight saving
changes" the time in my Java program is one hour ahead, as presented by
Date.toString for example, of the time presented in Windows XP.

A common failing of Windows, not Java. Test by using Java to display a time
you know to be in UTC (see below), and compare this with reality. Once you
have discovered that the problem is the faulty timekeeping in Windows (as
everyone always does, without any exceptions, worldwide), change it.

This problem arises because, unlike sane operating systems, Windows makes
its system real-time clock run in local time, then tries to juggle all the
local time/UTC time issues while using a source of *local* *time*. This
means that, unless the user is aware of this and is entirely clear about
how to keep things from getting out of sync, Windows can and will totally
screw up Java's timekeeping. Oh, did I add that turning off Windows
daylight time is an adequate meddle to cause all of the above?

Further
the useDaylightSavings method of the default TimeZone (as returned by
TimeZone.getDefault()) always returns true, no matter if the win xp
"daylight saving" box is checked or not.

Yes, that is right. Java doesn't know or care about the system time zone
settings. All Java does is try to acquire reliable UTC time from the host
operating system for use within Java. Unfortunately, Windows generally
cannot provide this with any consistency or reliability.

If Windows allowed the system real-time clock to run in UTC, all of this
would go away, because Windows could simply pass this time along to Java,
regardless of the user's meddling with Windows time zones and daylight time
settings. But this is just one of dozens of things about Windows that are
(1) broken, and (2) seemingly cast in concrete.

Run this class, read the output, and compare it to actual UTC:

import java.util.*;
import java.text.*;

public class Test {

public static void main(String[] args)
{
Calendar now = Calendar.getInstance();
DateFormat fm =
DateFormat.getDateTimeInstance(DateFormat.LONG,DateFormat.LONG);
fm.setTimeZone(TimeZone.getTimeZone("UTC"));
System.out.println("Date: " + fm.format(now.getTime()));
}
}

This program sould emit a date and time consistent with UTC anywhere, on any
system (unless of course the system is running Windows). Once you have
established that Windows cannot reliably provide you with UTC, a
requirement for any sane operating system, write a nasty letter to Bill
Gates.

 

[NB]

Hi all!
I have the following problem with jdk 1.3.1 on Windows XP Home edition:

If I uncheck the box "Automatically adjust clock for daylight saving
changes" the time in my Java program is one hour ahead, as presented by
Date.toString for example, of the time presented in Windows XP.

A common failing of Windows, not Java. Test by using Java to display a time
you know to be in UTC (see below), and compare this with reality. Once you
have discovered that the problem is the faulty timekeeping in Windows (as
everyone always does, without any exceptions, worldwide), change it.

This problem arises because, unlike sane operating systems, Windows makes
its system real-time clock run in local time, then tries to juggle all the
local time/UTC time issues while using a source of *local* *time*. This
means that, unless the user is aware of this and is entirely clear about
how to keep things from getting out of sync, Windows can and will totally
screw up Java's timekeeping. Oh, did I add that turning off Windows
daylight time is an adequate meddle to cause all of the above?

Further
the useDaylightSavings method of the default TimeZone (as returned by
TimeZone.getDefault()) always returns true, no matter if the win xp
"daylight saving" box is checked or not.

Yes, that is right. Java doesn't know or care about the system time zone
settings. All Java does is try to acquire reliable UTC time from the host
operating system for use within Java. Unfortunately, Windows generally
cannot provide this with any consistency or reliability.

If Windows allowed the system real-time clock to run in UTC, all of this
would go away, because Windows could simply pass this time along to Java,
regardless of the user's meddling with Windows time zones and daylight time
settings. But this is just one of dozens of things about Windows that are
(1) broken, and (2) seemingly cast in concrete.

Run this class, read the output, and compare it to actual UTC:

import java.util.*;
import java.text.*;

public class Test {

public static void main(String[] args)
{
Calendar now = Calendar.getInstance();
DateFormat fm =
DateFormat.getDateTimeInstance(DateFormat.LONG,DateFormat.LONG);
fm.setTimeZone(TimeZone.getTimeZone("UTC"));
System.out.println("Date: " + fm.format(now.getTime()));
}
}

This program sould emit a date and time consistent with UTC anywhere, on any
system (unless of course the system is running Windows). Once you have
established that Windows cannot reliably provide you with UTC, a
requirement for any sane operating system, write a nasty letter to Bill
Gates.

Excuse me if I utter obvious nonsense. I am a newbie. I was wondering
whether something could be done to retrieve UTC by using the variables:
boolean dstOn and current timezone.

Another approach I have in mind involves retrieving UTC from the Net (only
for connected machines).

Comments please.

 

[Svante Nicholas Arvedahl]

Thanx for your quick answer Paul!

A common failing of Windows, not Java. Test by using Java to display a time
you know to be in UTC (see below), and compare this with reality. Once you
have discovered that the problem is the faulty timekeeping in Windows (as
everyone always does, without any exceptions, worldwide), change it.

You're right the UTC time is wrong then the "daylight savings" box is
unchecked. Another way to put it is that Java is incapable of figuring out
what the correct UTC time is. All my other windows applications are able to
present the correct time.

Svante

 

[Svante Nicholas Arvedahl]

Excuse me if I utter obvious nonsense. I am a newbie. I was wondering

whether something could be done to retrieve UTC by using the variables:
boolean dstOn and current timezone.

The UTC time is what should be right from the start. All other time
manipulation in Java depends on that.
About dstOn (I assume you mean TimeZone.useDaylightTime()), there doesn't
seem to be a connection between the windows "adjust clock for daylight..."
box and the TimeZone.useDaylightTime().

Another approach I have in mind involves retrieving UTC from the Net (only
for connected machines).

That's an interesting apporach for getting the de facto time. For me it
seems like I need to get it from windows with JNI...

/Svante

 

[Illya Kysil]

Hello, Svante!
You wrote on Mon, 20 Oct 2003 08:22:34 GMT:

SNA> If I uncheck the box "Automatically adjust clock for daylight saving
SNA> changes" the time in my Java program is one hour ahead, as presented by
SNA> Date.toString for example, of the time presented in Windows XP. Further the
SNA> useDaylightSavings method of the default TimeZone (as returned by
SNA> TimeZone.getDefault()) always returns true, no matter if the win xp
SNA> "daylight saving" box is checked or not. I've tried setting XP up for both
SNA> the Stockholm time zone (gmt +1:00) and Central Time (GMT -6:00)

SNA> ...

TimeZone.useDaylightSavings = true if a time zone have daylight saving time range specified.
You should call TimeZone.inDaylightTime to know whether it is active for a given date.

Regards
Illya Kysil, software developer
Delphi/C/C++/C#/Java/Forth/Assembler
If it is NOT SOURCE, it is NOT SOFTWARE. (C) NASA

 

[Paul Lutus]

Thanx for your quick answer Paul!

You're right the UTC time is wrong then the "daylight savings" box is
unchecked. Another way to put it is that Java is incapable of figuring out
what the correct UTC time is. All my other windows applications are able
to present the correct time.

This is misleading. Java relies on the host operating system for accurate
UTC. Windows cannot be relied on to provide this information. The problem
is with Windows, not Java.

The Windows programs do not care about UTC, they use local time. Therefore
if the Windows time settings are munged, it doesn't matter (except to any
application that really needs UTC).

 

[Paul Lutus]

NB wrote:

Excuse me if I utter obvious nonsense. I am a newbie. I was wondering
whether something could be done to retrieve UTC by using the variables:
boolean dstOn and current timezone.

The problem is that all these assumptions about time zones are within Java.
Java doesn't have access to the asssumptions being made by Windows. So this
doesn't solve anything.

Another approach I have in mind involves retrieving UTC from the Net (only
for connected machines).

That will work. Seems like a lot of trouble to get around an operating
system deficiency.

 

[Paul Lutus]

Svante Nicholas Arvedahl wrote:

That's an interesting apporach for getting the de facto time. For me it
seems like I need to get it from windows with JNI...

No, becaue if you get it from Windows, Windows will reply inaccurately, just
as before.

 

[Svante Nicholas Arvedahl]

I have now solved the daylight savings problem.
After some more thinking I realized that the UTC time never was wrong (I
thought it was when I set the time in windows to be what my wall clock,
which was on the dst time, showed and unchecked the "daylight savings" box,
which gave me a UTC time an hour ahead of the real UTC time. But of course
it should since the wall clock was an hour ahead due to dst).
So the problem was only that Java doesn't know that daylight savings is not
used if the dst box in windows is not checked. Using JNI I was able to
retrieve the windows settings with GetTimeZoneInformation in Windows SDK
(kernel32.lib, windows.h), and change default TimeZone if the settings
didn't match. I really think this is something the VM should handle.

Svante