Using dates and times in a program is not always as straight forward as you might think. The issue is with timezones and daylight savings. Most people forget to use a timezone when they store dates. This might not seem like an issue if you think your program will never be used in another timezone, but it still is.
Timezones tell you how to convert your datetime from one timezone to the other. 10am in NYC is not the same 10am in Tokyo. What makes this all the more fun is the wonder idea of daylight savings time. Time will go backwards and forwards or seeming random days. Suddenly there are 2 different 11:59pm.
When you look at a file in windows explort, did you ever think about the missing timezone on the dates? You probably didn’t give it a second thought. But you should. You probably assume that it is showing the times in your current time zone.  Sadly you are more correct then you think. I found out about this after I read this link. It seems windows uses your CURRENT timezone to display the datetime. Whats the problem with this? If a file was created at 3/1 10:00pm and you look at the file in April, windows shows the file date as 11:00pm, even though the correct time should be 10:00pm.
Windows is smart enough to store the date in UTC/GMT/ZULU time, but when converting it back to your local timezone, it just uses your CURRENT timezone offset, instead of figuring out what it was on that date with DST factored in. I wonder if someone was trying to optimize out a few CPU cycles.
So next time you are looking at the access times on your files, remember that they could be up to an hour off from what the actual time was.