Why Daylight Savings Time is nonintuitive

RE: Why Daylight Savings Time is nonintuitive

RJ — Fri, 24 Oct 2003 11:02:00 GMT

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?

RE: Why Daylight Savings Time is nonintuitive

DotFrandsen — Fri, 24 Oct 2003 12:51:00 GMT

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?

RE: Why Daylight Savings Time is nonintuitive

Serge Wautier — Fri, 24 Oct 2003 14:41:00 GMT

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...

RE: Why Daylight Savings Time is nonintuitive

Steve — Fri, 24 Oct 2003 16:55:00 GMT

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...

RE: Why Daylight Savings Time is nonintuitive

Barnaby James — Fri, 24 Oct 2003 16:56:00 GMT

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?

RE: Why Daylight Savings Time is nonintuitive

Anonymous — Fri, 24 Oct 2003 16:58:00 GMT

"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?

RE: Why Daylight Savings Time is nonintuitive

Nate Silva — Fri, 24 Oct 2003 17:31:00 GMT

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.

RE: Why Daylight Savings Time is nonintuitive

MilesArcher — Fri, 24 Oct 2003 18:49:00 GMT

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.

RE: Why Daylight Savings Time is nonintuitive

runtime — Fri, 24 Oct 2003 19:52:00 GMT

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. :-)

RE: Why Daylight Savings Time is nonintuitive

Raymond Chen — Fri, 24 Oct 2003 21:12:00 GMT

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.

RE: Why Daylight Savings Time is nonintuitive

runtime — Fri, 24 Oct 2003 21:59:00 GMT

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?

RE: Why Daylight Savings Time is nonintuitive

Raymond Chen — Fri, 24 Oct 2003 22:09:00 GMT

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.

RE: Why Daylight Savings Time is nonintuitive

David Larsson — Fri, 24 Oct 2003 22:27:00 GMT

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!

RE: Why Daylight Savings Time is nonintuitive

Mike Dunn — Sat, 25 Oct 2003 00:12:00 GMT

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

RE: Why Daylight Savings Time is nonintuitive

Serge Khorun — Sat, 25 Oct 2003 02:46:00 GMT

> 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. 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.

RE: Why Daylight Savings Time is nonintuitive

Anonymous — Mon, 27 Oct 2003 02:01:00 GMT

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.

RE: Why Daylight Savings Time is nonintuitive

J. Peterson — Tue, 28 Oct 2003 00:06:00 GMT

Ah, now I know why doing XCOPY /D to a Samba server screws up for half the year.

RE: Why Daylight Savings Time is nonintuitive

J. Peterson — Tue, 28 Oct 2003 00:07:00 GMT

Ah, now I know why doing XCOPY /D to a Samba server screws up for half the year.

RE: Why Daylight Savings Time is nonintuitive

Ryan — Thu, 30 Oct 2003 20:57:00 GMT

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?

RE: Why Daylight Savings Time is nonintuitive

Eric Promislow — Fri, 31 Oct 2003 20:12:00 GMT

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.

RE: Why Daylight Savings Time is nonintuitive

Anthony Moore — Mon, 03 Nov 2003 21:53:00 GMT

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.

re: Why Daylight Savings Time is nonintuitive

John Doe — Sun, 02 May 2004 21:11:00 GMT

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 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.

.NET DateTime and Timezone: It Seems Simple, but It's Not

Mark Treadwell — Sat, 22 May 2004 02:37:00 GMT

re: Why Daylight Savings Time is nonintuitive

Raymond Chen — Fri, 18 Jun 2004 06:43:00 GMT

Commenting on this article has been closed. (I mean, come on, it's eight months old.)

DateTime and Timezone

Ohad's WebLog — Sat, 17 Jul 2004 17:00:00 GMT

How to fix the bogus daylight behavior of DateTime.FromFileTime()

Antimail — Tue, 31 May 2005 21:21:42 GMT

There is an important difference in the way the DateTime.FromFileTime(...) method adjusts for daylight...

Time zones make me cringe

Sorting It All Out — Mon, 03 Apr 2006 22:13:26 GMT

I did talk about a particular time zone issue earlier today....
And I see that Anthony posted about...

WebServices and Timezone

BitsAndBytes — Mon, 03 Apr 2006 22:39:24 GMT

Have you ever had to deal with consumer and provider of webservices residing in different time zones...

Think of Windows as a hedonist

Sorting It All Out — Mon, 29 Jan 2007 16:33:25 GMT

Windows has some time zone information stored in its innards. But Windows only lives in the now; it pays

Your questions: "How does Windows handle historical events with daylight saving time updates?"

Satisfy Me — Fri, 02 Mar 2007 02:32:59 GMT

I received a question from a customer who had applied the Windows OS update for daylight saving time

WebServices and Timezone

Bits&Bytes — Wed, 15 Aug 2007 08:02:11 GMT

Have you ever had to deal with consumer and provider of webservices residing in different time zones

Mike’s Lookout » Blog Archive » Windows DST Handling

Mike’s Lookout » Blog Archive » Windows DST Handling — Wed, 19 Dec 2007 02:32:41 GMT

PingBack from http://www.belshe.com/2007/12/18/windows-dst-handling/