The Old New Thing

This will all be moot once people wake up and abolish this hack.  Give me Zulu time or give me death.

John > Commenters to the original article also point out that timestamps should be stored and manipulated as UTC, and that they should be displayed/taken as user input in the local time format.

Where user input is ambiguous or invalid, the UI needs to get clarification, but then that's always the case with validating user input.

Once it's in the system, it should never be a problem.

Karellen,

Unfortunately, it's not that simple. Consider a calendar manager, and a recurring meeting that happens every Friday at 2:00 PM. With high probability, this means 2:00 PM local time, even when daylight savings time kicks in or out.

Furthermore, it probably means 2:00 PM local, even if Congress changes the daylight savings time rules after the meeting was scheduled.

The worst part is that the displayed time for dates beyond daylight time also shifts one hour. In Windows Explorer.

Oh! That's the reason a Windows Smart Phone alarm rings an hour early after the DST switch, if you program the alarm before the switch!

@Jim Lyon:

What you describe has intersting implications when going global.

Say someone in California wants to schedule a recurring meeting Friday 2pm. Now, try and import that meeting inside a German calendar. The meeting invite has to really be handled as "2pm current DST-correct pacific time", no matter what the time zone in Germany is. So... It would have an 8 hour difference this week, but 9 last week or next week (we are right in the week where Europe switched but not most of US).

In fact, what you really want to store is which timezone the invite was created in, no matter what timezone it will be used in.

Well, unless of course the person who created the invite wanted to schedule it at 3am German time. I never found a way in most Calendars to specify which time-zone I wanted to schedule my meeting in without changing my environment itself.

Bahbar said:  I never found a way in most Calendars to specify which time-zone I wanted to schedule my meeting in without changing my environment itself.

This is partly because, to the best of my knowledge, there aren't any operating systems that track time changes for more than one locale at a time. World-wide, daylight savings time transitions occur at about 100 different times.

All of which goes to show that the notion of "store it in UTC and don't worry" is overly simplistic.

@Jim Lyon:

To be fair, Karellen was talking about timeSTAMPS, i.e. references to single, definite points on a global timescale. For these, storing things as UTC does solve everyting.

Finding out which point in absolute time to speak about in the first place is a different can of worms, but still mostly a user-interface one.

I think we've covered once again why DST is one of the most brain-dead dumbass stupid ideas the universe has ever conceived.  

Mr Cranky > I can agree on that one!

FFS - if you want more daylight in your evenings over the summer, get up an hour earlier and work 7 - 5 instead of 8 - 6. You get the same effect, only you don't need to make all the clocks in the damn country wrong!

I hardly know anyone who doesn't have this sort of latitude in their working hours these days.

> "I never found a way in most Calendars to specify which time-zone I wanted to schedule my meeting in without changing my environment itself."

Apple's iCal can do this. In preferences -> Advanced check the "Turn on time zone support" box.

You can now select the time zone for each event and also change which time zone iCal is currently using for displaying events (top right of the window).

"FFS - if you want more daylight in your evenings over the summer, get up an hour earlier and work 7 - 5 instead of 8 - 6. You get the same effect, only you don't need to make all the clocks in the damn country wrong!"

I already work 7 - 3:30.  They won't let me start at 6:00am (I usually get in the door around 6:20, and do my OT before the day starts)

(me?  An early bird?  what gives you that idea.  Feels strange going to bed when it's still light out in late June (hint, when you get up at 4:00am, bedtime comes real early)

I want more daylight in the evenings all year. Why do we have to go back to winter time?

Random managed code / date handling story: I once installed Windows on a machine whose BIOS date was wrong.  I mean well and truly wrong.  I mean, so wrong that it is (1) a valid date and time for NTFS yet (2) not a valid date and time as far as the CLI's filesystem handling code is concerned.

Result: all .NET applications throw an exception on startup, because they try to read the timestamp on the global assembly cache directory, and fail.  Oops.

Henning Makholm: good point.

Think of it this way.  Most people work 9-5 (or some similar timeframe).  That's symmetrical around 1pm.  The day (when we're not in DST) is symmetrical around noon.  Something's wrong there.  The day's biased towards mornings being brighter and evenings darker...?!

DST all year round.  It's the only way that makes sense.

@Jules, Henning Makholm:

Apparently, you two need another couple of whacks with the clue stick.  Try to understand that the universe, the space-time continuum, and your dog do not care what number you assign to any particular part of the day.  If you feel you want more daylight after work, then get your ass out of bed earlier and leave work earlier.  But f*****g around with clocks not only does nothing to actually accomplish what you want, it causes some serious problems that have already wasted man-centuries of programming time.  So stop it.  Now.

btw, I work <7-16< most days.  Is that balanced enough for you?