back to article Microsoft warns of bugs after nation pushes back DST switchover

The decision last month by Chilean leaders to delay a switch to Daylight Savings Time (DST) by a week could cause headaches for some Windows users if they don't implement the workaround outlined by Microsoft. The Chilean government on August 9 announced it was moving the start of DST by a week, from September 4 to September 11 …

  1. Dan 55 Silver badge

    "The US also extended DST in 1986 [...] forced Microsoft to adapt Windows"

    I think the most Windows 1.0 ever understood was local PC time. I can't even remember Windows 3.1 having timezones, Windows 95 had them though.

  2. Nick Ryan Silver badge

    Hard Coding Ahoy

    The abject idiocy of this is that it should be nothing more than a data file update. Given Microsoft's total failure in making this change suggests that idiot developers have obviously got in the way here and coded the time zones into the operating system instead.

    1. DS999 Silver badge

      Re: Hard Coding Ahoy

      I'm not sure how it is done, but I'll bet it is a "data file" somewhere in the Windows filesystem. Maybe in a file combined with some other somewhat related data, but something they could easily update. It is absolutely not hard coded into binaries. No one would do that.

      The problem is the short notice. Even if Microsoft was notified of this the minute the government made the decision (and you can bet they weren't, because obviously no one making this decision thought through the consequences) they probably have enough change control layers that rolling out an update to the timezone data files in less than a month is not feasible. They may have some bypasses built into that process for a currently exploited zero day, but they aren't going to do that for a mess a government creates for itself.

      Given the long and storied history of time zone / dst screwups in computers over the decades, creating a process where you can rush through updates due to the silly whim of a government to change their time zone policy with a few weeks notice would be stupid. I will fault Microsoft for many, many things, but not this.

      1. X5-332960073452

        Re: Hard Coding Ahoy

        ".... No one would do that."

        I think you underestimate Microsoft.

    2. StuartMcL

      Re: Hard Coding Ahoy

      It's just a set of Registry values in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\<ZOne name>

      The full zone info is stored in a 44 byte TZI structure in each zone's entry

      The problem is that Chile doesn't have its own zone entry, it is considered to be under "Pacific SA Standard Time."

      It's probably time that MS created a separate Zone entry for Chile considering the number of times they have changed. That's easy enough to roll out with the next update, but every machine in Chile would need to have it's regional settings changed to the new zone.

      1. DS999 Silver badge

        Re: Hard Coding Ahoy

        The problem is that Chile doesn't have its own zone entry, it is considered to be under "Pacific SA Standard Time."

        And that's probably not Microsoft's fault, I'm guessing there is an international standards organization that specifies Chile is part of that timezone? Now I suppose Chile could have fought in the past for having their own time zone just to make this easier, but that would have required they foresee wanting to go with different DST settings tha the rest of their zone.

        With various states in the US going their own way, and even some counties within states going in different ways, time zone data is only going to become more unmanageable.

        Maybe we need a DNS extension using TXT records that can specify custom timezones? Then a government can manage those from their top level domain, i.e. the US would have one for each state, and the states could delegate that info down to the county level. So if you configure your OS to point at it'll grab the necessary data and cache it, and check however often the expiration is set for (a week or a month I guess) to see if it has changed. If there is no DNS entry it will use the currently installed datafile for that location.

        I think we're moving beyond trying to centrally manage timezones. Could it be hacked? Its DNS so sure, but there are far more tempting targets for DNS hacking than making everyone late for meetings.

        1. katrinab Silver badge

          Re: Hard Coding Ahoy

          Chile is in the following time zones:



          and Pacific/Easter

          1. Korev Silver badge

            Re: Hard Coding Ahoy

            I hope they don't add Pacific/Christmas

            1. katrinab Silver badge

              Re: Hard Coding Ahoy

              We already have an Indian/Christmas ...

            2. Stevie

              Re: I hope they don't add Pacific/Christmas


              That would be crackers.

      2. J.G.Harston Silver badge

        Re: Hard Coding Ahoy

        Rather than having a one-off time zone for Chile, time zone information should be territory-based, as with languages. So, rather than 'Pacific South America' or something, it should be cl-00=UTC-0800, us-rm=UTC-0900, ca-02=UTC-0500 or something.

        1. Kristian Walsh Silver badge

          Re: Hard Coding Ahoy

          Time-zones are a very complicated problem to solve, and that approach has been ruled out a long time ago, because time-zones, DST observance, and territories are an overlapping set with no hierarchical arrangement: even your “simple” US example is thwarted by the Hopi Nation lands located in the State of Arizona (the former observes DST, the latter does not).

          Having debugged a lot of date/time code over the years, I'm going to say that whether or not Microsoft issued that fix on time would be largely irrelevant. By default, databases store UTC for DATETIME unless you go out of your way to be an idiot, so DST is invsible to these. The issues are in calculations and presentation on those stored dates, and that’s where hackery begins.

          I can guarantee that a huge number of developers will have hard-coded the DST changeover dates in their code - especially if they were using Java, whose date libraries are historically so bad that they encourage hand-rolling of alternatives. (Yes Jodatime, now java.time, is acceptable, but it took nearly two decades to become standard!)

          Calculating durations and repeating events that cross the DST changeover is something I’ve rarely seen done right first time, and often the “second time” fix is something like “if (start<'hardcoded_DST_changeover_date' && end>'hardcoded_DST_changeover_date') ...” that kind of code is just waiting around for something like this to happen.

    3. david 12 Silver badge

      Re: Hard Coding Ahoy

      The problem is that when you made a recurring international meeting for "10AM Monday local time", what 10AM was that? The old 10AM, when all the other people will be attending, or the new 10AM, after your weekly 9AM meeting?

      When you start work at 9AM, are you authorized to use the secured database? That authorization starts at UTC, mapped to the olde DST schedule.

      Like the man said: devices could report incorrect times in the OS and applications, scheduled tasks may not run when expected, and timestamps on transactions, files, and logs will be off by an hour.

      There's a million things like that. Unscheduled DST changes are never just a "data file update".

    4. doublelayer Silver badge

      Re: Hard Coding Ahoy

      Updating the time zone is just a file, well actually not quite, but someone else has pointed out that Chile shares time zone data with other regions that didn't do this. Even if it was just them, though, there'd be problems. So Microsoft rushes out an update which updates just that file. Now everyone in Chile needs to install it. In two weeks. You don't get that universal response when it's an actively-exploited zero day. You're not going to get it here either.

      So some machines have the patch and others don't. Say hello to lots of computers disagreeing about what time it is, and therefore what time any other reference is talking about. Systems that work by sending times between them will end up with answers that are an hour apart, and that's if the programmers have been careful only to ever use UTC for internal storage. If they ever use local time, even temporarily, except when processing user input, they can have even more bugs. This also makes Microsoft and everyone else release an emergency patch just to get into this state, which takes time and effort.

    5. Anonymous Coward
      Anonymous Coward

      Re: Hard Coding Ahoy

      Android requires to reboot the phone when the time zone data are updated... isn't it just a data file for the Linux kernel has well?

      1. MrBanana

        Re: Hard Coding Ahoy

        Not the kernel. It has no real knowledge of time except for UTC when it last got booted, and it checked the RTC in the BIOS. Later on in the startup process, a network ping will tell the user based systems what the actual time is, and apply whatever timezone setting the user has chosen. Not always perfect, especially if you have inconsistent data as seems to be the case here. I don't think this is an MS issue, if Chile had made the decision to be part of of block of countries, rather than be a single entity, then that is now their problem.

      2. OhForF' Silver badge

        Re: Hard Coding Ahoy

        Probably not done because of issues in the kernel but to stop issues with apps not knowing they have to reschedule events like meeting notifications or alarm time if the time zone is not changed but it definition was altered.

      3. Korev Silver badge

        Re: Hard Coding Ahoy

        > Android requires to reboot the phone when the time zone data are updated... isn't it just a data file for the Linux kernel has well?

        You're making the assumption that the Android phone still gets updates...

    6. Bryan W

      Re: Hard Coding Ahoy

      Hardcoded or "data file", it doesn't matter. It'll need to get updated either way. Just a matter of the format of the bytes involved, but thanks for playing.

  3. Anomalous Cowturd


    My Linux installs updated tzdata a couple of days ago, this was probably why. I didn't bother checking the changelog.

    Why does Microsoft make such a big deal about updating a data file?

    1. StuartMcL

      Re: Hmmm...

      > "My Linux installs updated tzdata a couple of days ago, this was probably why. I didn't bother checking the changelog."

      Does it have a separate entry for Chile as opposed to Pacific SA Time? If not, you have the same issue.

      1. mickaroo

        Re: Hmmm...

        My version of Linux appears to have an entry for Santiago.

        I've heard a rumour that may be somewhere in Chile...

        1. doublelayer Silver badge

          Re: Hmmm...

          Be careful. It's labeled by largest city, so it doesn't mean only Chile is in there. I think it is this time, but that doesn't always hold. For example, if the U.S.'s proposal to go to permanent summer time goes in, the tzdata is going to have to change because right now, Canada uses tzdata files with American city names, so unless they do the same, they'll need to change files and everyone in Canada has to start using the new Canadian files. If other countries were included in the America/Santiago file, they didn't make this choice and would have been affected as well.

          1. Anonymous Coward
            Anonymous Coward

            Canada uses tzdata files with American city names

            Rarely these days. All Linux installs I've done in the past ~decade+ leave me in "America/Toronto", and IIRC once or twice I've seen "America/Ottawa". Neither is in the United States.

            1. Haff

              Re: Canada uses tzdata files with American city names

              But Canda and the USA are both in America, so the naming seems valid

              If you look at the full list most are Continent\City

            2. doublelayer Silver badge

              Re: Canada uses tzdata files with American city names

              It depends on whether they use a database with a lot of copied zones or a simplified one that doesn't use duplicates. If you're using the more basic one, then except for the Atlantic provinces and Newfoundland, they use the largest cities (New York, Chicago, Denver, Los Angeles). Anything that has hard-coded these labels will need updating. Probably most Linux installations use the full TZ database. Many embedded ones use the smaller one to save on storage, so they won't be as lucky.

    2. Ken Hagan Gold badge

      Re: Hmmm...

      "Why does Microsoft make such a big deal about updating a data file?"

      Because although updating the file is easy in principle, half your user base isn't going to do it, some unknown population of third-party applications will screw up because their programmers had never heard of using UTC internally, and still others will screw up because the distance between UTC and local has changed in between generating the UTC value and the time it actually refers to.

      DST is a god-awful mind-fucking mess even when it is well-defined. Actually changing DST is stupid. Changing it within a week or two of the changeover date is self-harm.

  4. Lorribot

    i don't think the client devices (including phones and MacOS and other OSes) will be as badly affected as the servers, these may have transactional time stamps that may have legal consequences if they are incorrect.

    And don't forget all those IoT devices that may end doing weird stuff on not sending their spy data off to Samsung correctly, god it could be really bad.

  5. EmilPer.

    Why is DST still a thing ?

    I currently live in UTC+2/UTC+3 but I could not care less if the Sun rises at 5 or at 7 or at 12 as long as I don't have to be jetlagged twice a year ...

    Kill DST, please.

    1. DS999 Silver badge

      Re: Why is DST still a thing ?

      As long as it kills standard time and we're permanently on "daylight savings" where I live, I'm fine with it. But I'll fight like hell if you try to put me on standard time all summer long and birds start chirping at 3am in midsummer.

      1. Anonymous Coward
        Anonymous Coward

        Re: Why is DST still a thing ?

        Ask yourself why most countries that attempted to stay on DST reverted their decisions - i.e. Chile, Russia - and why countries in North Europe decided to end DST. Because the fact that birds start chirping earlier in Summer is a lesser problem than going to bed when it's not yet dark enough, and have dawn too late in Winter.

        1. jmch Silver badge

          Re: Why is DST still a thing ?

          "is a lesser problem than going to bed when it's not yet dark enough, and have dawn too late in Winter."

          In Northern Europe during winter, dawn is too late whether you're on DST or not!

          The real problem is that while humans evolved, and for many millennia since civilised society existed, humans have worked to a daylight schedule, working more in summer and less in winter at higher latitudes. Industrialisation and corporate culture forcing people to work fixed schedules throughout the year is the root problem here. Without that, there would be no need of DST, people would have different schedules in different seasons, and work whatever time works for them as long as the work gets done. (That, by the way, is a natural extension of going back to home working) .

          That, or have everyone migrate by 20 degrees latitude every autumn/spring

          1. Cuddles

            Re: Why is DST still a thing ?

            The really weird part is that, at least in the UK, one of the most vocal groups opposed to ending DST is farmers, who are also one of the few groups who still overwhelmingly work to a daylight schedule (or at least to the needs of animals and crops, which amounts to the same thing) and not the clock.

      2. Chris Roberts

        Re: Why is DST still a thing ?

        The birds chirp based on the light level not on what time humans decide to call it. Our time systems contain a the concept of midday/noon when the sun is nominally at its highest point. To shift your clock around so that physical midday does not match timed system midday seems a bit contrary. Granted where you are mucking around with DST it means you have the convenience of having more evening light without changing your working hours from '9to5' to '8to4'. If you are not going to use DST then use a time zone the gives you the best match to midday and just sort out your waking hours as appropriate.

    2. ITS Retired

      Re: Why is DST still a thing ?

      UTC does not observe the so-called Daylight saving Time. Nothing is actually saved. Especially not with the resulting confusion twice a year.

      Mucking about with the time zones, either results in gaps in the 15 degree separations in the time zones. or overlaps.

      No DST, no computer confusion. No wondering what time it is for that meeting, somewhere else. Are they on DST, or Standard time? Do they change with everyone else, or days, weeks differently.

      Stop it already. Too much energy is being spent twice a year, when a simple fix is at hand. Just stay on standard time the year around.

  6. Tromos

    If DST was a good idea...

    ...the druids would have arranged for Stonehenge to be picked up and rotated 15 degrees twice a year.

    1. Yet Another Anonymous coward Silver badge

      Re: If DST was a good idea...

      They do moving the Avebury stones for British summer time

      (Of course they had to pretend it was a joke when news leaked out)

  7. Auntie Dix

    The Chile Zone: Meat-Based, No Beans

    Assign Chile its own zone entry and get it over with. Micro$haft should have seen this undonkeyed cart rolling toward it, years ago.

    DST is an anachronistic PITA.

    1. Stevie

      Re: The Chile Zone: Meat-Based, No Beans

      Local times are the PITA.

      Everyone should be on Zulu time* and lump it.

      *Zulu time defines the baseline as the time “Zulu” was shown on BBC1 on Christmas Day 1980, that being stated as 00:00:00 Zulu time.

      1. John PM Chappell

        Re: The Chile Zone: Meat-Based, No Beans

        "*Zulu time defines the baseline as the time “Zulu” was shown on BBC1 on Christmas Day 1980, that being stated as 00:00:00 Zulu time."

        I realize (hope?) you were probably joking, but just for clarity of readers who might not know better, this is not the case. It is most likely based on Sandford Fleming's system, but in any case came from making official already existing usage in the armed forced of NATO, specifically the two most important (in practice) the UK and the USA.

        Z (Zulu, from the NATO phonetic alphabet) is UTC (Historically, UT1/GMT), A through M (J - Juliet is skipped) are positive offsets (UTC+1, ... UTC+12), N through Y are negative offsets starting with UTC-1. Twenty-five letters used, one for each offset, and one for UTC itself.

        Aviation exclusively uses it (UTC) in communication, to ensure nobody is confused about timing.

  8. Jamesit

    When Canada and the US changed the beginning and ending of DST, MS provided a tool to edit the time zones called TZEDIT.EXE.

    "Tzedit - Time Zone Editor

    Tzedit - Time Zone Editor Tzedit is a freeware utility that allows you to edit time zone information in Windows. All parameters can be edited such as time zone name and information, time zone location on the world map (MapID), Microsoft Time Zone Index, MUI strings for time zone name and Dynamic DST settings. This utility works on any version of Windows from Windows 95 to Windows 10."

    download link:

    1. Anonymous Coward
      Anonymous Coward

      I might be inclined to trust the download if it were hosted on a web page.

      1. Jamesit


        I didn't think of that, I'll check it out, I hope I didn't link to a bad download.

        Edit to add. says it's clean.,lc2nx2u0dq,wags95jxza isn't working for me.

      2. Anonymous Coward
        Anonymous Coward


        There's an whole article about it, because a similar case already arose 16 years ago with Guatemala, and it seems that back then, there were indeed Microsoft tools to handle the situation:

        What happened that it's now more complicated?

        1. doublelayer Silver badge


          I can't find confirmation, but maybe Guatemala gave more notice so that article could get written? Otherwise, maybe they decided asking every user in a country to manually edit registry values, at that article does, isn't a functional solution.

  9. Pascal Monett Silver badge

    "enough time to build, test, and release"

    What ?

    Borkzilla is testing something ?

    That's news.

    1. Anonymous Coward
      Anonymous Coward

      Re: "enough time to build, test, and release"

      They need to ensure the spill chucker hasn't kicked in and changed it to Chilli

  10. Anonymous Coward
    Anonymous Coward

    DST is anachronistic

    My employer (security infrastructure) always uses GMT/UTC everywhere for legal integrity of data. Conversion to local time is done when it is displayed to the user.

    Only poorly written software will base time decisions on local time. (Probably most of it, then.)

    I feel daylight savings should be abandoned.

    The airline / ATC industry also uses GMT/UTC universally because it saves lives.

    1. Giles C Silver badge

      Re: DST is anachronistic

      Yep most software runs in gmt/utc and the sensible stuff just has an offset in the display the user sees.

      Correlating log files when dst kicked in was always fun - some massive holes or duplicate entries depending on which end of the year it was.

      Once everyone agreed to keep the timezone the same it was a lot easier.

      1. MrBanana

        Re: DST is anachronistic

        DST is a massive pain the arse - timestamps should be unique right? I do not need two different 02:30s.

        1. Norman Nescio Silver badge

          Re: DST is anachronistic

          DST is a massive pain the arse - timestamps should be unique right? I do not need two different 02:30s.

          They are unique if you record the time offset from UTC with the timestamp (ISO 8601).

          2022-10-30T01:30:00+01:00 and 2022-10-30T01:30:00+00:00 are different, unique times. (Note the clock moves back an hour at 02:00, not 03:00)

          If you are not doing this, the software that generates your timestamps is broken.

    2. katrinab Silver badge

      Re: DST is anachronistic

      I do the same. It still causes problems. The display-conversion still has to be done correctly. External data comes in local time and has to be converted to UTC.

      1. Ken Hagan Gold badge

        Re: DST is anachronistic

        And there was the example cited earlier, of scheduling a meeting at "local time X". What the Chilean government have effectively done is change the meaning of that data after the fact. This isn't something that your meeting software will even be aware of unless it follows the local news.

    3. Norman Nescio Silver badge

      Re: DST is anachronistic

      Well, yes, but UTC has its own problems as it has leap seconds, which Google cope with in a non-standard manner by 'smearing' the clock over several hours to avoid discontinuities in the logs etc. See also Google Cloud:Making every (leap) second count with our new public NTP servers

      We could do with a 'monotonic' time standard for use by computers which is converted to local time for display purposes. While UTC is fine for most stuff, by definition, it can have leap seconds added or removed as it attempts to stay roughly in synchronisation with the Earth's rotation rate, which is variable.

      There isn't an official monotonic time. TAI comes close, as an aggregate of several hundred atomic clocks, but it is worked out statistically 'after the event', so there isn't a TAI timeserver as such.

      Meta::cpan - Time::Monotonic - A clock source that only increments and never jumps

      Blargh (2010-09): gettimeofday() should never be used to measure time - Monotonic timers

      If you really want to get into the details of time standards, astronomers have been considering this for decades, and I can heartily recommend Steve Allen's web-pages.

      POSIX already requires that zoneinfo offsets handle offsets of seconds.

      Time Scales

      Epoch Time vs. Time of Day

      Starting from the top (there is a lot of depth), the initial web-page is:

      UTC might be redefined without Leap Seconds


    4. Anonymous Coward
      Anonymous Coward

      Re: DST is anachronistic

      "The airline / ATC industry also uses GMT/UTC universally because it saves lives."

      I'm really, really sure that I never, ever bought a plane ticket using an UTC timestamp. So it's not using it "universally". It's using it "internally". And if it doesn't have the proper, up-to-date information to convert UTC to local time to display it accurately, then people are going to be mightily confused and will miss their flight.

    5. Anonymous Coward
      Anonymous Coward

      Re: DST is anachronistic

      Even better, proper developers/engineers just use timestamps based on an epoch not a converted date/time...timestamp translation should occur at the point you view the data...not the point you store it.

      1. Ken Hagan Gold badge

        Re: DST is anachronistic

        Still doesn't help you when a politician changes the meaning of "3pm local time" to mean a different UTC timestamp, *after* you've written that timestamp into your internal data.

      2. katrinab Silver badge

        Re: DST is anachronistic

        As other people have pointed out, if I schedule a meeting for 14:00 London Time on a particular date, and Liz Truss changes our time zone rules, Liz Truss has changed the time of our meeting.

        Or if the meeting is actually in Scotland, and Nicola Sturgeon changes Edinburgh time to not be the same as London time, then ...

  11. Anonymous Coward
    Anonymous Coward

    Here for the inevitable lol omg wtf M$ comments..

  12. Robert Sneddon

    Ob XKCD

    "You can tell when someone's been a programmer for a while because they develop a deep-seated fear of time zone problems".

    1. Anonymous Coward
      Anonymous Coward

      Re: Ob XKCD

      Or a sysadmin: after being bitten by it, I've forbidden to crontab anything between 2 and 3am,

      For once, I disagree with the XKCD mouseover.

      Case in point: between 1584 and 1752, there was a 10+ day mismatch between the British and continental calendars. While we happily accepted the new rules made up by Pope Gregory, you guys over the Channel and your colonies further west were a bit slow to accept he was right. And yet, History never bothers to explain that things happened at different dates during that period.

      1. WolfFan Silver badge

        Re: Ob XKCD

        Don’t rag on L’Anglais too much, the Russkies were much worse. The October Revolution actually took place in November… The Bolshies, once in power, made the change.

        1. Anonymous Coward
          Anonymous Coward

          Re: Ob XKCD

          IIRC there were riots for various reasons to do with the missing dates.

          1) people paid monthly rents on a specific day - and suddenly they were getting fewer days for their money.

          2) some people were apparently convinced (conspiracy theory?) that their lives had actually been shortened.

      2. that one in the corner Silver badge

        History never bothers to explain..

        Could not reach History to pass your complaint on, but was able to leave a message with Kleio.

      3. Strahd Ivarius Silver badge

        Re: Ob XKCD

        Remember February 30th 1712!

  13. Anonymous Coward


    Time zones are the problem. Sundials are the answer.

    1. that one in the corner Silver badge

      Re: Sundials

      Just so long as you remember to adjust the gnomon angle on your wristdial when travelling on the M1*

      *other roughly N-S roads are available

    2. Anonymous Coward
      Anonymous Coward

      Re: Sundials

      Sundials were obsolete once "railway time" became the necessary standard in the UK eg the significant accumulating difference for stations' timetables between London and Bristol. The parallel advent of the telegraph system enabled automatic synchronisation.

  14. mevets

    Programmers and dates.

    Programmers have trouble understanding dates. A surprise to anyone who has never met one.

  15. Ken Moorhouse Silver badge

    I keep saying it...

    Wherever there is DST, change the clocks by half an hour, then leave them set that way forever.

    1. Strahd Ivarius Silver badge

      Re: I keep saying it...

      You live in India?

  16. Anonymous Coward
    Anonymous Coward

    My UK central heating timer is standalone. It came with time (and presumably date) apparently preset in the factory. It has some sort of internal power back-up - whereas the earlier model had a user battery that was invariably exhausted when needed. It knows when the clock should change in the UK - so presumably hard coded.

    At the moment one less clock to alter twice a year*** - but there are often murmurs of about a new approach to DST.

    ***Most of the clocks in the house are MSF controlled - which dies not guarantee a smooth transition as they tend to save battery power by only checking with MSF occasionally during a day. The MSF standard possibly should have been UTC - with predictive indicators in the transmission that a change would be needed. However that would probably have upset the use of the sequence of sixty one second transmissions to encode the date and time for each minute..

    1. Norman Nescio Silver badge


      The MSF standard possibly should have been UTC

      MSF should be monotonic, with a field to show the total of leap seconds since the epoch, to allow calculation of UTC, and another field to show the civil time offset from UTC. That way, you get a useful standard time, with built in data to allow calculation of the current civil time ( current UTC with or without 'summertime' ).

      Distributing civil time as a time standard is not helpful.

      Civil time is defined by the Earth's rotation with respect to the Sun, which is variable, and gently (on a long term average) slowing down. Our (mostly atomic) time standards keep time better than the Earth's rotation, so while it makes sense for civil time to be in lock-step with the day length, it does not make sense for a distributed time standard to be based on the Earth's rotation. Using UTC does not solve the general problem because it incorporates pretty much randomly occurring leap seconds*. Using a proper standard with a known conversion to UTC does.

      *As someone pointed out, trying to predict when a leap second will be needed to keep UTC in step with the Earth's rotation is like trying to predict the weather.

  17. Erik Beall

    I just use unixtime for everything and have zero problems because I never interface with other humans or require crontab... In all seriousness though I do use unixtime in most custom logging I do with so much less hassle for devices distributed across time zones, and then I had to work with a company that used JMP to look at various device data (defining their epoch in seconds since a hundred years ago or something I can't even remember bc it's so arbitrary and specific to the program) and a bunch of devices with real time clocks that use an epoch starting in 1980. Ugh!

  18. Anonymous Coward
    Anonymous Coward

    Microsoft test their updates ‽

    Who would have known it.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like