Java6 gives wrong file timestamp during daylight savings on windows

[Darren Marsh]

1) If I create a file at 10am in windows the timestamp is 10:00, regardless of whether it's daylight savings or not.

2) In Java 6 I do System.out.println("Time: "+ new Date(file.getLastModified())); the time will show as 9:00 during daylight savings time. In Java 5 the time will be 10:00 as expected.

3) In Java 6 if I do a setLastModified and set it to 10:00, then in windows it shows the timstamp as 11:00. In Java 5 it will be 10:00 as expected.

This only happens during daylight savings, only on windows, and only in Java 6. I've tried URLConnection.lastModified() but it gives the same result.

My problem is that I need to check the times on files created by another program, but during daylight savings, Java 6 thinks all the files are 1 hour older than they really are. If I want all files created in the last 5 minutes it will never find anything during daylight savings time because it thinks they're all > 1 hour old.

So how can I get the correct timestamp in Java6?

[Jim Yingst]

Where are you located?

For your JDK 5 installation, did you ever update it specifically for timezone fixes?

What happens when you run this:

System.out.println(System.getProperty("java.version"));
System.out.println(Locale.getDefault());
System.out.println(TimeZone.getDefault().getDisplayName());

Try that using both JDK 5 and JDK 6. Is there a difference?

[Darren Marsh]

I'm in Australia. This application was originally written for 1.4 and hasn't had any problems or need any java fixes to make it work. Only Java 6 has this problem.

Either something has changed with Java 6 time handling (modifications for the changes to US daylight savings perhaps?) and I need to change something in my program to make it work properly or there's a bug.

Java 5
1.5.0_06
en_AU
Coordinated Universal Time

Java 6
1.6.0_03
en_AU
Coordinated Universal Time

[Darren Marsh]

I just tried it on another machine and it's out by 10 hours, so it doesn't appear to be a daylight savings problem. I've got NFI what is going on now

You wouldn't think it'd be too much to ask just say file.getLastModified() and get the correct effing time

EDIT: actually, I'd forgotten that I was setting the timezone to UTC to try and fix this problem. Getting rid of that fixed the 10 hour problem. Stuffed if I know why that only affected 1 out of the 3 machines I'm testing on. My only conclusion is that Javas timezone handling is a mess.
[ February 21, 2008: Message edited by: Darren Marsh ]

[Charlie Hubbard]

It's not Java. It's Windows bizarre handling of time and DST.

http://www.codeproject.com/KB/datetime/dstbugs.aspx?df=100&forumid=2218&exp=0&select=229121

[Mike Simmons]

Darren Marsh wrote:I'm in Australia. This application was originally written for 1.4 and hasn't had any problems or need any java fixes to make it work. Only Java 6 has this problem.

Well that's suspicious right there - Australia changed their rules twice since JDK 1.4 came out, no? I suspect that your tests are not as comprehensive as they might be. Could be you're just now noticing a problem that's been around for a while. Where in Australia are you? Saying "Coordinated Universal Time" seems bogus, since UTC doesn't have daylight savings at all.

Charlie wrote:It's not Java. It's Windows bizarre handling of time and DST.

Well, I'm all for blaming Windows in most cases. But here, I'm more inclined to blame the very concept of DST. It's inherently evil. It would be bad enough if it followed consistent rules from country to country, and from year to year. But it doesn't. It's something that any random country (USA, Australia) can change on a whim.

On the plus side, this creates some work for us programmers. Huzzah! Except, well, I have enough work already, thanks. Any rules that exist solely to make things more complicated need to be jettisoned, IMO.

Yeah, I know the chance of changing this is minimal (at the moment). But hey, you raised the blame issue - I just want the finger pointed squarely at the true culprit.