Welcome Knowledge Base article 932955 readers! Remember, the information on this Web site is not official Microsoft documentation. Daylight Savings Time ends this weekend in most of North America and Europe, so it seems a good time to discuss the whole problem of Daylight Savings Time and timestamps.
A common complaint is that all the time zone conversion functions like FileTimeToLocalFileTime apply the current Daylight Savings Time (DST) bias rather than the bias that was in effect at the time in question.
For example, suppose you have a FILETIME structure that represents "1 January 2000 12:00AM". If you are in Redmond during the summertime, this converts to "31 December 1999 5:00PM", seven hours difference, even though the time difference between Redmond and UTC was eight hours at that time. (I.e., when people in London were celebrating the new year, it was 4pm in Redmond, not 5pm.)
The reason is that the time got converted from "1 January 2000 12:00AM UTC" to "31 December 1999 5:00PM PDT". So, technically, the conversion is correct. Of course, nobody was using PDT on December 31, 1999 in Redmond; everybody was on PST.
Why don't the time zone conversion functions use the time zone appropriate for the time of year?
One reason is that it means that FileTimeToLocalFileTime and LocalFileTimeToFileTime would no longer be inverses of each other. If you had a local time during the "limbo hour" during the cutover from standard time to daylight time, it would have no corresponding UTC time because there was no such thing as 2:30am local time. (The clock jumped from 2am to 3am.) Similarly, a local time of 2:30am during the cutover from daylight time back to standard time would have two corresponding UTC times.
Another reason is that the laws regarding daylight savings time are in constant flux. For example, if the year in the example above was 1977 instead of 2000, the conversion would have been correct because the United States was running on year-round Daylight Savings Time due to the energy crisis. Of course, this information isn't encoded anywhere in the TIME_ZONE_INFORMATION structure. Similarly, during World War 2, the United States went on DST all year round. And between 1945 and 1966, the DST rules varied from region to region.
DST rules are in flux even today. The DST cutover dates in Israel are decided on a year-by-year basis by the Knesset. As a result, there is no deterministic formula for the day, and therefore no way to know it ahead of time.
(Warning: .NET content ahead; two days in a row, what's gotten into me!?)
Compare the output of FileInfo.LastWriteTime.ToString("f") with what you see in the property sheet for a file that was last written to on the other side of the DST transition. For example, suppose the file was last modified on October 17, during DST but DST is not currently in effect. Explorer's file properties reports Thursday, October 17, 2003, 8:45:38 AM, but .NETs FileInfo reports Thursday, October 17, 2003, 9:45 AM.
En gang til for prins Knud: Win32 does not attempt to guess which time zone rules were in effect at that other time. So Win32 says, "Thursday, October 17, 2002 8:45:38 AM PST". Note: Pacific Standard Time. Even though October 17 was during Pacific Daylight Time, Win32 displays the time as standard time because that's what time it is now.
.NET says, "Well, if the rules in effect now were also in effect on October 17, 2003, then that would be daylight time" so it displays "Thursday, October 17, 2003, 9:45 AM PDT" - daylight time.
So .NET gives a value which is more intuitively correct, but is also potentially incorrect, and which is not invertible. Win32 gives a value which is intuitively incorrect, but is strictly correct.
I suspect that the .NET behavior was for compatibility with Visual Basic, but I don't know for sure.
Thanks for the reminder about the time change :)
I know you tend to write mostly about the history of Win32 and why some things are the way they, it’s all good stuff … BUT .. I’d be interested to know if you think Win32 has any future (apart from Win64) now that everything seems to be focused on .Net. Obviously there are some things that .Net does not currently do (audio without DX for one) and relies on either COM or Win32 to provide, but will anyone still be using HWNDs in the future?
En gang til for prins Knud? Did you learn that on your recent trip to Denmark?
Couldn’t this issue be solved once and for all by raising a DST flag somewhere in the file’s metadata? I know there are no such thing as simple changes to a complex system, but … hypothetically? Or am I completely missing the point?
Ha ! I’m one of the victims of that behaviour of FileTimeToLocalFileTime. So thanks for clarifying the issue.
I must say I don’t agree with the decision taken : Because the ideal solution to a problem is nearly impossible to solve correctly (for the reasons you mentioned), you (well, maybe not you specifically, Raymond) decided to trade that ideal solution for a much simpler one which is IMO much worse. One just can’t rely on this API because it gives wrong results in around 50% of cases.
I’d rather have a solution that has some drawbacks (yes, which 2:30AM is intended if there are 2 that day. Let’s decide it’s the first one) but correctly replies in most cases (BTW, if there is no 2:30 AM that day, I’d like to receive E_CANT_CONVERT). And sorry for my Israeli clients, and sorry for some of my european clients who want to look at data in october 95 before DST transition switched from end of september to end of october. But at least, we would something that works fairly well for most people instead of something which is plain wrong for around half of data.
BTW, DotFrandsen, the problem doesn’t exist for files only. FILETIME is more and more used for signal recording and datalogging, especially in industrial process control. time_t used to be the standard. FILETIME has the advantage to go sub-second… and it also solves the year 2038 limit of time_t (Yes, i’ll be retired or not programming anymore but I do care for my kids ;-) )
BTW-bis, Raymond, do you know why time_t is signed. Looks like it makes us lose 68 precious years…
Does Win32 have a future? It sound slike you think .NET can stand on it’s own, not so. All of the .NET Framework rides on top of Win32 calls at some level or other…
Daylight savings time rules vary by location (as well as historically) — for example some parts of Indiana don’t obey Daylight Savings, Japan doesn’t use it at all and in some countries (like Israel) it happens at a different time every year. I imagine .NET just uses the US rules?
"Does Win32 have a future? It sound slike you think .NET can stand on it’s own, not so."
As I pointed out, there is a lot of stuff that still relies on .Net – I gave audio as an example. My point is that if MSFT is going to PUSH people towards .Net for standard desktop apps, what future will Win32 have in the wild?
I think the .NET behavior makes sense. Anyone who needed a strictly correct, invertible, timestamp would be using UTC.
Time zones are really just a display transformation of UTC. It makes no sense to do things like timespan calculations or anything else other than final display output using timezones.
Win32 is being too technical in trying to turn a human-readable display format into something that is invertible.
here’s a real world example:
Today, I set up a meeting for Oct 30th at 8am Pacific time on the Webex meeting service. The time zones to choose from were all DST. I didn’t know if I should choose one time zone earlier or later to adjust for it. To make a long story short, I think it set it for the right time.
I have always thought we daylight savings should be REVERSED: -1 hour in the spring, +1 hour in the fall. That would give us more daylight at the end of the day, when modern man needs it. Current daylight savings gives us more daylight at the beginning of the day, which I guess would help farmers more..? If I wake up at 7:00 AM, having the sunrise at 6:00 AM does me now good. In fact, the sun will now sent earlier for me. bogus. :-)
There are some interesting issues here, more complex than I can squeeze into a comment; I’ll make a full blog entry someday.
runtime: That’s what daylight savings time does. "Spring forward" – so when the sun sets naturally at 9pm, your clock says 10pm. You get an extra hour of daylight at the end of the day.
Farmers actually hate daylight savings time since it means that when they get up at 5am to milk the cows, it’s still dark out. (Because the sun naturally rises at 5am, but the clock has been fiddled to read 6am; if you get up when the clock reads 5am, the sun is not yet up.) I never understood why the farmers didn’t just get up to milk the cows at 6am. It’s not like the cows go on daylight savings time.
You are right, but I think that extra hour of sunlight would be more useful during the WINTER than the summer. During the winter, the days are shorter (the sun rises later and sets earlier). So wouldn’t an extra hour of daylight during the winter be more useful?
During the winter, you’re already using all the daylight. The sun rises at 7am and sets at 5pm. Shifting it around wouldn’t help much. (During the summer, you sleep through the first few hours of the day, so shifting them to the evening is a net gain.) And it would mean schoolkids standing in pitch dark on icy roads waiting for the school bus.
DST is a terrible idea that should be scrapped. I would be very happy if we all used UTC and didn’t worry so much about getting up 7-ish in the morning and having only a small shadow when the clock says 12-ish.
More seriosly, the DST changes twice a year are like having the Y2K problem over and over, but without the media hype. Let’s have a show of hands: How many of you experienced problems during Y2K? Ok. And how many of you have issues with both old and new software at least once a year because of DST? There you go!
If you think FILETIMEs are bad, check out Eric Lippert’s entries on the horrors of VT_DATE and other VB-related date quirks —
http://blogs.gotdotnet.com/ericli/PermaLink.aspx/b58da9e1-8624-4d17-bfc4-dc943fdc4968
I think because truck to pick milk up still comes at 5:45am, not caring about if it’s light or dark :)
I don’t think "kids waiting for the school bus" reason is entirely correct. Poor kids from Alaska and Canada still wait for the bus in a dark. :)
If I recall correctly at some west-European country (Hungary?) they used to shift regular work hours at summer to something ridiculously early like 5-6am to have more light after work time.
I think the solution is to just enact permanent daylight savings. Light at the begining of the day is an annoyance – you’re in bed, you want it to be dark so you can sleep. Light at the end of the day is useful.
Ah, now I know why doing XCOPY /D to a Samba server screws up for half the year.
Ah, now I know why doing XCOPY /D to a Samba server screws up for half the year.
What about using GetTimeZoneInformation() followed by TzSpecificLocalTimeToSystemTime() (Win32 API calls) to perform time conversions?
Are you saying the algorithm used by the latter function does not always produce correct output?
The win32 method isn’t 100% perfect. Someone’s run into the
.Net gotcha and posted his problem on the Dotnet language
dev list, but here’s where the win32 method breaks down. The
functions aren’t perfectly invertible:
Normally
t1 = utc-time-to-local-time (local-time-to-utc-time (time t)) == t
But because we’re dealing with physical computers, and not
abstract mathematics, if the cutover occurs while
we’re evaluating this expression, we would still have a problem:
<In PDT (or some other summer-time time zone>
get and push time()
; say time represents 2003-10-26T01:59:59.999…
call local-time-to-utc-time
; leaves new time on stack, 2003-10-26T08:59:59.999… (add 7)
; process is swapped out as the system moves to standard time
call utc-time-to-local-time
; leaves new time on stack, 2003-10-26T00:59:59.999… (subtract 8)
store t1
So you can’t win 100% of the time, but the Win32 method fails less
often than the .Net method.
I am the owner of the .NET DateTime and Time Zone.
There seems to be some some confusion about how the Win32 and .NET systems relate to each other. .NET actually uses the same time zone information that Win32 uses, and this does not "Default to US", but the user chooses their time zone from a localized dialog box at install time.
However, as mentioned above, .NET has a couple of key differences:
1. It is more like VB in that most APIs return local instances rather than UTC instances.
2. The UTC<->Local conversion works differently as Raymond described in the original post.
Feedback I have received is that (1) creates reliability problems compared to Win32 because most APIs are subject to 1 hour of data loss. However, most people like (2), because changing into and out of DST does not retrospectively change old times. Many peopl have to write their own logic to correct for this Win32 behavior.
Now that the PDC has started, I can annouce that the data loss problem is corrected in Whidbey. The DateTime now stores some additional flags so that it can tell the difference between Standard and DST in the repeated hour.
Arizona really need to observe DST during the summer between April and October. To assure that they’ll have a good taste of having daylight/twilight later in the evening if the government allow to use DST which means still on the MST. However, since Arizona do not observe DST which means they are on California time (PST) will get dark early and California will still have daylight a little while longer. If Arizonas were smart enough, they can tell the local government to move the clock 1 hour foward and still be on MST, not on PST. The Indian Reservation do observe daylight savings is on MST and the rest of the state is on PST. You may want to check on http://www.sunrisesunset.com and most of USA have daylight after 8pm. Best if the people in the state of Arizona to persuade the government or vote.
Advantages daylight savings for Amtrak, Airlines, Freight trains, other transportations, sports including Arizona Diamondbacks.
The heat will not make any difference during the summer. Texas heat remains hot and the state observe DST and so is New Mexico.
Farmers hate daylight savings and they are trying to activate people’s lives.
Commenting on this article has been closed. (I mean, come on, it’s eight months old.)
There is an important difference in the way the DateTime.FromFileTime(…) method adjusts for daylight…
I did talk about a particular time zone issue earlier today….
And I see that Anthony posted about…
Have you ever had to deal with consumer and provider of webservices residing in different time zones…
Windows has some time zone information stored in its innards. But Windows only lives in the now; it pays
I received a question from a customer who had applied the Windows OS update for daylight saving time
Have you ever had to deal with consumer and provider of webservices residing in different time zones
PingBack from http://www.belshe.com/2007/12/18/windows-dst-handling/