Working with ambiguous and invalid points in time in managed code


Public Service Announcement: Daylight Saving Time ends in most parts of the United States this weekend.

I pointed out some time ago that Win32 and .NET deal with daylight saving time differently. Specifically, Win32 always deals with the time zone you are currently in (even if it's not the time zone that corresponds to the timestamp you are manipulating), whereas .NET deals with the time zone that was in effect at the time the timestamp was generated.

For more details on the latter, I refer you to Josh Free from the BCL Team Blog, who some time ago explained how to work with ambiguous and invalid points in time in managed code.

Comments (16)
  1. Anonymous says:

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

  2. Anonymous says:

    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.

  3. Jim Lyon says:

    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.

  4. Anonymous says:

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

  5. Anonymous says:

    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!

  6. Anonymous says:

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

  7. Anonymous says:

    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.

  8. Anonymous says:

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

  9. Anonymous says:

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

  10. Anonymous says:

    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.

  11. Anonymous says:

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

  12. Anonymous says:

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

  13. Anonymous says:

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

  14. Anonymous says:

    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.

  15. Anonymous says:

    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.

  16. Anonymous says:

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

Comments are closed.