Don’t be so fast to discount those oddball time zones


This weekend marks the beginning of Daylight Saving Time in most parts of the United States, the first year under the new transition rules in the Energy Policy Act of 2005. Pay extra attention to your clocks this weekend. If you have a device that automatically adjusts for Daylight Saving Time, and it hasn't been updated for the new transition rules, you may end up having to adjust your clock four times this year:

  1. On March 11 (when Daylight Saving Time begins under the new rules) you have to adjust the time forward.
  2. On April 2 (when Daylight Saving Time began under the old rules) your device will automatically adjust forward, and you'll have to adjust it backward to return the clock to normal.
  3. On October 28 (when Daylight Saving Time ended under the old rules) your device will automatically adjust backward, and you'll have to adjust it forward to return the clock to normal.
  4. On November 4 (when Daylight Saving Time ends under the new rules) you have to adjust the time backward.

Okay, that's the end of the public service announcement.

I try to commemorate the Daylight Saving Time transition days by writing about time zones, and this time, it's about those time zones whose displacement from UTC is not a perfect hour multiple.

Some years ago, I was involved in a discussion over an issue that was affected by time zones. In particular, the feature in question organized its data by hour, and since the raw data format was UTC, the items were grouped by hour UTC. This works great for time zones that are an integral number of hours from GMT, but if you're in a time zone that is not, then the grouping will come out weird.

The program manager for the feature dismissed my concerns. "You're talking about those oddball time zones that are like 3½ hours from GMT? I say, tough for them. We should be optimizing for the major markets, not the fringe cases."

"Um," I replied. "One of those so-called fringe cases happens to be the second most populous country in the world."

Microsoft has already run into trouble with time zones and India. I suggested that we probably shouldn't upset them a second time.

(We also saw earlier that India doesn't group digits in threes.)

Comments (38)
  1. David Candy says:

    I’ve heard it said (well gasps of shock horror from yanks) that TV in the USA starts on the hour rather than the half hour. Surely not.

  2. James says:

    Talking of time zones, sometime last year a (non-IT) colleague mentioned a very strange problem to me: about once a month, his laptop clock would jump eight hours ahead! He’d set it back to the right time manually, and all would be well – for the next month, until it happened again.

    My first suspicion was right: he had the time zone set eight hours off, and once a month, Windows was correcting the time using SNTP (which uses UTC) and adjusting for his chosen timezone…

  3. Matt Green says:

    Is the "second most populous country in the world" a reference to last night’s Are You Smarter Than A Fifth Grader question? Or just mere coincidence?

  4. Indian timezones and digit groups says:

    I’ll try to say this as eloquently as possible:

    What the hell is wrong with them!

  5. Tim says:

    Think yourself lucky! A friend of mine moved to Israel, and he says they don’t have DST rules – some officials just sort of get together at roughly the right time of year and decide when DST change-over is going to be(!)

    As stated here:

    http://wwp.greenwichmeantime.com/time-zone/asia/israel/time.htm

    "According to the Office of the Secretary General of the Ministry of Interior, there is no set rule for Daylight-saving time changes."

    Freaks :-)

    I guess people in Israel just disable DST on their computers, and change the computer clocks manually.

  6. Julio says:

    @Tim: In Brazil, the starting and ending dates for DST change every year. Besides, roughly half of the states observe DST, while the others don’t.

    We don’t understand why there’s all this fuss about these DST rule changes…

    System administrators are used to change the timezone information of servers and desktops when the starting/ending dates are set by the government. Home users usually don’t bother that much and manually adjust the clock two times, just like Raymond wrote in the post.

    There’s a KB article for this: "How to configure daylight saving time dates for Brazil" (http://support.microsoft.com/kb/317211). A funny line:

    "DISCLAIMER Please note that this information changes every year, and the contents of this article will be updated as needed."

  7. A number of systems and specifications have a rule in their representations of local times that says that the absolute value of the offset from Greenwich can never exceed 720 minutes (12 hours).

    But when New Zealand is on DST, they are at Greenwich + 780 minutes (13 hours).

    An incomprehensible hack has been inserted into the XML Schema specification to deal with this.  http://www.w3.org/TR/xmlschema-2/#date-lexical-representation

  8. Maurits says:

    Didn’t the manager notice that the timestamps on his email were 8 hours off?

    For those who are in the Pacific time zone but still on Windows 2000, there is an easy workaround… set the time zone to Arizona time on March 11th.  Then, sometime between October 28 and November 4, set it back to Pacific.

    Or just modify the timezone registry settings.

  9. Stephen Jones says:

    Why not always set the clock to GMT and do the adustments in your head?

  10. John says:

    I propose that all hardware devices should store time in UTC and DST should be eliminated.  Software should handle time zone adjustments.  Now, where is my Nobel Prize?  Seriously, there is no reason NOT to store time as UTC on all but the most trivial devices.  No, providing backwards compatibility for WordPerfect for DOS is not a compelling reason.

    [I guess you don’t care about backward compatibility with Windows Vista either. -Raymond]
  11. John says:

    But why does Windows Vista store local time?  Because XP did.  And why did XP do it?  Because 2000 / ME did.  And why did 2000 / ME do it?  Because 9x / NT did.  And why did 9x / NT do it?  Because DOS did.  And why did DOS do it?  (Honestly, I don’t know why DOS did it.  Did they take it from CP/M, and if so why did CP/M do it?  Or did they make the decision by themselves, and if so why?)

    So we have this annoying but relatively minor problem today due to a design decision initially made at least 25+ years ago.  Is Windows 2020 going to keep this chain of backward compatibility intact?  God forbid Lotus Notes 1.0 won’t run under Windows 2020!  Vista dropped support for 16-bit DOS applications, so obviously at some point backward compatibility gets taken out of the equation.

    [I agree that almost nobody cares about Lotus Notes 1.0, but I’m not sure what you’re proposing. That Vista+1 be incompatible with Vista? -Raymond]
  12. Puckdropper says:

    I’m not a fan of auto-DST adjusting devices.  In this case, closed non-software upgradable devices such as clocks create more trouble than they solve.

    I’ve been known to throw 3-4 OSes on a machine, and come DST they ALL want to update my clock.  (After that, I started turning off the DST update when I installed an OS.)  It’s much easier for me to open the calender–uh… time and date settings–and adjust the time.

  13. Cooney says:

    [I guess you don’t care about backward compatibility with Windows Vista either. -Raymond]

    I honestly don’t care about Vista. XP yes, vista no. Of course, I only run corporate versions, so I don’t have to deal with the weird activation thing.

  14. Jonathan says:

    @Julio

    A big part of the problem is that the US DST rules were fixed for too long, they were last modified just over 20 years ago.  

    Because they were stable during basically all of the personal computer revolution they got encoded into many different pieces of software and operating systems.  In many cases there weren’t provisions made to adjust or disable the rules easily.  (And because the rules were so simple and so fixed it seemed easier to build then directly into each piece of software rather that utilizing whatever date/time library an OS might offer)

    If the US had been like Brazil, where apparently the rules change every year, then likely no-one would have tried to build DST rules into their software and we wouldn’t be dealing with incorrect rules now.  (Or at a minimum the rule set would have been tied to central libraries, so only one place needed to be updated with whatever the rules would be this year).

  15. Jonathan says:

    As for Israel:

    Before 2005, the time for DST was topic for political debate – conserving energy vs. convenient prayer times (!). As you can imagine, this was rather unpleasant.

    Since 2005, we have a fixed schedule. But, the beginning is according to the regular calendar, and the ending is according to lunar calendar (to conincide with the holidays) – something I doubt will get coded into software.

    What people do: If you set your Windows timezone to "Jerusalem (GMT+2)", the "adjust automatically" heckbox will gray out. Most people set the time themselves. I do the correct thing, and change the timezone to some GMT+3 (Kuwait is m farotive).

  16. John says:

    I guess I am proposing that.  Somewhere down the road between Vista and Vista + N changes will inevitably need to be made.  Vista dropped 16-bit DOS support, introducing an incompatibility with Windows XP.  I suppose you could incrementally phase out various features of 16-bit DOS compatibility, so technically that incompatibility could have been introduced in stages.  I don’t know the technical details behind it so I can’t say.  But you can’t gradually change from storing local time to storing UTC time; you are either doing one or the other.  So if somebody finally decides to do it, Vista + N + 1 will be "incompatible" with Vista + N.  I for one will welcome the change.

  17. David Walker says:

    That infoplease link doesn’t work for me… the little blue circle in the tab spins forever.

  18. Bramster says:

    "Vista dropped 16-bit DOS support, introducing an incompatibility with Windows XP"

    Does this mean that my character-oriented, file tools  written in Turbo C won’t work on Vista?

    In that case, I’ll never upgrade to Vista.

  19. dave says:

    How hard would it have been to add a "Set hardware clock to UTC" checkbox to the time zone settings?

    If Vista still doesn’t support that, then I’m going to have to say "gratuitiously broken" here.  The additional cognitive load on the user in this case is easily worth being able to play nicely with other OSs running on the same machine, and making it optional will allow playing nicely with older versions of Windows as well.

  20. PatriotB says:

    "Vista dropped 16-bit DOS support, introducing an incompatibility with Windows XP"

    Not true.  I just ran a DOS program under Vista with no problems.

    Maybe you’re thinking of Vista x64?  But XP x64 didn’t support DOS programs either.

  21. Adrian says:

    A few jobs ago, I managed VAX/VMS systems.  VMS kept local time rather than GMT+offset.

    To handle standard time/daylight time changes, you could set up a batch job to change the system clock in the middle of the night.  But if you system was used ’round the clock, the sudden time warp could upset other batch jobs in progress, especially in the Fall, when we set the clocks BACK.

    So the trick was to write a program to change the speed of the clock, and have it run fast or slow over a period of time.  For example, in the spring you could let it run at 125% of normal speed for four hours (from midnight to *five* in the morning!).

  22. ChrisMcB says:

    "I propose that all hardware devices should store time in UTC and DST should be eliminated.  Software should handle time zone adjustments.  Now, where is my Nobel Prize?  Seriously, there is no reason NOT to store time as UTC on all but the most trivial devices.  No, providing backwards compatibility for WordPerfect for DOS is not a compelling reason."

    What are you arguing? And what problem are you trying to solve?

  23. M Hotchin says:

    Anyone who’s ever heard the CBC tell of up- comming programming will understand this…

    "The world will end at Midnight – 12:30 in Newfoundland."

    Now, I *know* it’s not the same market size as India, but it’s nice we can at least represent all the time zones that exist in just North America!

  24. David Candy says:

    Apparantly the new vidio drivers don’t allow direct access to the video hardware (which is what happen in full sceen mode), So text mode programs will be fine in a window. Also I’ve been told full mode is available in a virtual pc and if using XP video drivers (but my xp drivers cause blue screens).

  25. Kuwanger says:

    What I don’t understand exactly is, why exactly is it the case that Wordperfect for DOS would be broken?  While you’d store in hardware the UTC, it’d be a system library that’d do the auto-translation to/from UTC (which, as I understand, is already done anyways to keep NTFS file timestamps happy).  So, what’s the problem, exactly, with making it so that DOS programs (and every other application) are lied to about the “real” hardware time, except for the fact that it might be a good bit of work?

    [Maybe I should just stop writing new content and start recycling old content. I already discussed this over two years ago. -Raymond]
  26. More backwards than thou says:

    Friday, March 09, 2007 10:53 AM by Indian timezones and digit groups

    I’ll try to say this as eloquently as possible:

    What the hell is wrong with them!

    Yeah.  We should use Roman numerals instead of those newfangled HINDU-Arabic digits.  As a bonus, we’d get more backwards compatibility.

    And to think, one time zone for an entire country.  No wonder it’s so confusing to those who have 6 time zones.

    Friday, March 09, 2007 2:30 PM by John

    (Honestly, I don’t know why DOS did it.  Did

    they take it from CP/M, and if so why did

    CP/M do it?

    Well who was going to teach all those Grandma CP/M users how to compute offsets from UTC?

    And while we’re at it, who’s going to teach all those Grandpas on certain standards committees about the advantages of UTC over GMT?  Do we really want all our clocks to be 20 seconds backwards and gradually get backwarder and backwarder?  I thought Gregory already showed why adjustments need ruling, if you get my drift.

  27. dcook says:

    As for running stuff under Vista or Vista64, I suggest looking into Virtual PC. The Virtual PC blog recently had an entry detailing how to easily set up a shortcut that launches Virtual PC, starts your DOS app, and lets you essentially pretend that it is just running in a Window. I suppose it isn’t quite as nice as having the back-compat layer built into Windows, but on the other hand you get much better DOS emulation by running a real copy of DOS.

    Virtual PC is freakin’ awesome, and really easy to use. Give it a try. (VMware might be more powerful, but I can be up and running with Virtual PC before I’ve even completed filling in the "application for product keys" for VMware.)

    As for hardware clocks, I’m still firmly in the camp of UTC hardware clocks for new PCs. I’ve read Raymond’s comments, and there are some good arguments, but I’m not entirely convinced. Windows already keeps all internal timestamps in UTC. Now it just needs a little bit of work to allow either UTC hardware clocks or local hardware clocks. Most users won’t care, and Windows can simply go on doing what it currently does, but a few will be happy with the additional flexibility. I don’t care what current or previous operating systems do/did – that is completely irrelevant. And the average user doesn’t even have to see this as an option, so the average user doesn’t enter into it either.

    Most users don’t install their own OS. They get the computer from the factory with Windows pre-installed. The factory can decide whether to set the hardware to UTC or local, and it is largely irrelevant as long as they use the same setting when they pre-install Windows. If the user has to re-install, they can be presented with the same dialog they get today – "please fix the time and pick a time zone". Windows can handle the rest however it wants. It can even consistently set the clock to UTC+(random number), and nobody will know the difference as long as the Windows clock gets set correctly when Windows boots. Windows just has to store the offset between the hardware clock and local time in the registry somewhere.

    Even better would be to add this offset to the CMOS. That would avoid the whole issue quite nicely, if you ask me.

  28. ericduran@hotmail.com says:

    I know this is just a stupid rant, but I would really like to kick the nutts of the stupid politician that suggested DST in the first place. For some places, it just doesn’t work (i.e. south Mexico, we end up using a bit more energy during DST!). In my personal opinion, the mess created by changing to/from DST is greater than the saving’s benefit (if any).

  29. Puckdropper says:

    [Maybe I should just stop writing new content and start recycling old content. I already discussed this over two years ago. -Raymond]

    What could be neat is a randomly selected "supplimental post of the day" where one of your archived posts is chosen and displayed in some manner.  It could introduce new readers to old content, which may be a bit of the solution of "how is this [common question] done?"

  30. bramster says:

    What could be neat is a randomly selected "supplimental post of the day" where one of your archived posts is chosen and displayed in some manner.  It could introduce new readers to old content, which may be a bit of the solution of "how is this [common question] done?"

    Or, you could buy Raymond’s book, which has given my some incredible insights.

    Thanks, Raymond.

  31. bramster says:

    @dcook

    Thanks for the heads-up.   I harken back to the Windows 95 introduction, which broke every program I had written using the compact memory model.  Now, it may have been something I had done wrong, but programs I had written in 1985 suddendly behaved as if there was a hardware program. . . i.e. failing without any kind of consistency.  I rewrote the programs limiting myself to the small memory model; a lot of work, and a re-thinking of how to name temporary files.  Switching to windows 2000, my original programs worked again.

    Any parallel experiences out there?

  32. Kuwanger says:

    “[Maybe I should just stop writing new content and start recycling old content. I already discussed this over two years ago. -Raymond]”

    Are you talking about this post: http://blogs.msdn.com/oldnewthing/archive/2003/10/24/55413.aspx  or this post: http://blogs.msdn.com/oldnewthing/archive/2004/09/02/224672.aspx or some other post (I’d linkify the urls, but I don’t know how much html is allowed in a post)?

    As per the first link, it sounds like it’s already an issue of LocalFileTimeToFileTime not giving a sensical response if you give an impossible local time, and there’s nothing particularly logical about making a non-function (mathmatically) invertable; I can see why there’d be a backwards compatability issue, though.  Also, I don’t see the logic of saying that an existing structure provides insufficient information to “guess” when there’s nothing stopping one from making a new structure to provide such information (and allow others to provide it, possibly); again, I can see how that might be a backwards compatability issue.

    As per the second link, the argument about dual-booting is at least marginally logical, but one could argue that one might very well be dual-booting with Linux or some other *nix that works just fine with UTC.  I guess the converse argument would be that Microsoft optimizes for the common case, but I am a little surprised that there isn’t seemingly even the option given considering how much work has to be done to handle UTC anyways.  Also, I can understand how it might be rather “silly” to force people to have to understand UTC to program their clock.  But how many people seriously go into the BIOS to program their clock?  Most people would use Windows regardless and the minority of people who would dare muck around in BIOS settings (and possibly screw up their system) should be at least technically capable enough to deal with UTC.

    I’m sorry I didn’t do a search of past posts before commenting.  I hope that I discussed the articles you were talking about.  And I can see how there might, somehow, be backwards compatability issues.  But it sounds like the procedures in question (and those like them) could at any time break due to changes in DST, anyways, so I’m not sure how exactly breaking them intentionally or change an unreasonable expectation (after all, you rightly point out that you can’t tell one local file time of 2:30am from another) would be any more damaging than the current situation.

    [Don’t forget that many BIOSes come up automatically under various conditions. -Raymond]
  33. Archangel says:

    @Maurits:

    "But when New Zealand is on DST, they are at Greenwich + 780 minutes (13 hours)."

    Nice to know someone’s thinking of us. Despite allegedly being "GMT+12", we’re only actually 12 hours ahead of the accepted time in England for two pairs of two weeks at either end of the year. It’s all a bit confusing for those of us with relatives over there…

    We’ve also got the Chatham Islands to screw things up more. They’re 45 minutes ahead of us, so more than 12 hours ahead of GMT the whole year around. I haven’t noticed an option in Windows for this, but with a population of 717 they’re not exactly the world’s second most populous country ;-)

    I shan’t even mention Tonga. They’re just cheating anyway.

  34. David Walker says:

    Dave: "How hard would it have been to add a "Set hardware clock to UTC" checkbox to the time zone settings?"

    It’s already there… No additional check mark is needed: Just go to the Time Zone tab and choose one of the two GMT settings.  The offset is zero.  UTC is, after all, based on GMT.

  35. BryanK says:

    David Walker — Um, not quite.  That will store UTC (well, it’ll store GMT, with or without the DST offset depending on time-of-year and the state of the DST checkbox), but it will also show the user GMT.

    I suspect that Dave was talking about storing UTC in the hardware clock (so that on bootup you don’t have to offset it before setting the system clock, at shutdown you don’t have to apply an offset before setting the hardware clock’s value, and at DST changes you don’t have to modify the hardware either), but still showing local time to the user.  That way the time they see still makes sense to them.

    (Or we could just get rid of time zones and DST entirely, in the rest of the world, and get everyone on one clock.  I wish.  Unfortunately most people wouldn’t get it.)

  36. dcook says:

    @bramster: The closest I’ve come was where Turbo Pascal programs stopped working when CPUs exceeded 200 MHz. I don’t remember hitting any memory model issues, but then I just stuck with Pascal for most stuff (medium, I think).

  37. AndyB says:

    talking about screwing things up, the newly patched version of localtime() will return this years DST settings.. So when you ask for a UTC timestamp from, say, 21 March 2006, it will tell you one that is wrong by an hour. (as this year 21/3/07 is DST value, last year is was not).

    So, storing times as UTC is also generally broken. Perhaps this is why systems should store values as their local times, not UTC.

    Getting rid of DST probably makes sense to you as a (lazy) developer, but doesn’t makes sense to real people who live in the world where it gets light and dark differently during the year :)

  38. GregM says:

    Andy, Raymond already talked about that, and Kuwanger linked to it in this post.

    http://blogs.msdn.com/oldnewthing/archive/2003/10/24/55413.aspx

Comments are closed.