Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Java6 gives wrong file timestamp during daylight savings on windows  RSS feed

 
Darren Marsh
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Where are you located?

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

What happens when you run this:


Try that using both JDK 5 and JDK 6. Is there a difference?
 
Darren Marsh
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!