back to article tz database community up in arms over proposals to merge certain time zones

The time zone database hosted at the Internet Assigned Numbers Authority (IANA) has been updated following threats, earlier this year, of a fork over a proposal to merge time zones. The update, the 2021b release of the tz code and date, was published over the weekend and omits some, but not all, of the issues that have caused …

  1. Anonymous Coward
    Anonymous Coward

    She who controls the past

    controls the future.

  2. Anonymous Coward
    Anonymous Coward

    She who commands the future, conquers the past.

    1. Michael Hoffmann Silver badge
      Black Helicopters

      He who controls the spice, controls the universe!

      Wait, am I in the right comment thread?

      (icon is actually an ornithopter)

  3. John Robson Silver badge

    Is the database really that big

    that the merge is necessary in any way?

    I don't really see that there is much additional overhead to keeping the separate, not like they update five times a day each.

    1. Pascal Monett Silver badge
      Facepalm

      Re: Is the database really that big

      The database is less than 500kb.

      Five. Hundred. Kilobytes. We can leave it as it is for the next hundred millenia before we start getting into a size issue.

      This really is a storm in a teacup.

      1. Tom 7

        Re: Is the database really that big

        So it should be spooned not forked!

        Well neither but they wont let me play with knives any more.

    2. Flocke Kroes Silver badge

      Re: Is the database really that big

      /usr/share/zoneinfo/ is 3528kB so no, it is absolutely tiny on a twenty year old desktop, laptop or server. On embedded systems this was often an issue. Every year it becomes an issue less often as embedded systems grow bigger.

      Twice a year at the transitions between UTC and Bergholt Stuttley Time my TV changes the time by one hour in the wrong direction so it always gets the time wrong by one hour. I am sure this is because someone trimmed the zoneinfo database or rolled his own. Microsoft infamously got DST wrong once: they set local time back one hour at 01:00 local time - then again every hour until people set the RTC to the correct time through the BIOS.

      Time is surprisingly tricky and lots of PFYs throw themselves into the common pot-holes because they think they are Time Lords. Although it is theoretically possible that a standard way to reduce the size of zoneinfo would reduce errors I am convinced that the exact people who should use it will not bother to RTFM.

      1. Greybearded old scrote Silver badge

        Re: Is the database really that big

        Up voted just for the Discworld reference. Nicely done.

      2. l8gravely

        Re: Is the database really that big

        Amen brother! I have to vaguely help mantain a database of old newspapers, and the contortions I have to go through to support sorting old dates is horrendous. It's especially tough in Europe where the calendars weren't unified for a long long time, so getting dates to agree between different countries is seriously tough work.

      3. DS999 Silver badge

        Re: Is the database really that big

        For embedded systems maybe they could create a make option that specifies a time horizon - i.e. "make EPOCH=2020" and it doesn't include any data prior to the year 2020.

        For an embedded system like a wireless router that never has reason to reference to times earlier than when it goes on sale, that would seem a reasonable thing.

        1. John Robson Silver badge

          Re: Is the database really that big

          Why would anything embedded want anything other than UTC?

          Being slightly serious though - what micro embedded devices need to report local time to a user without some other device doing the display and interaction?

          I suppose there might be a few things like thermostats which have local interaction with a clock involved, but... Have a "DST" toggle button?

          1. DS999 Silver badge

            Re: Is the database really that big

            Because modern routers have UIs designed for ordinary people to use them. If Linksys or whoever is selling a router with parental controls so you can keep your kids off the internet after 10pm, the typical person is going to expect that to mean 10pm where they live, not 10pm in Greenwich.

            And as you say thermostats, smart TVs, home alarm systems, or heck in fridges these days. The need for embedded systems to understand time zones is only increasing as more and more devices become "smart" (whether needed or not)

            But unless they need to refer to times in the past (before they were first sold) they could use a much more streamlined tz datafile.

            1. veti Silver badge

              Re: Is the database really that big

              The router doesn't need to know that. The interface that the user plays with, via Windows or whatever, is a whole separate piece of software and it already knows the user's accustomed UTC offset.

              1. DS999 Silver badge

                Re: Is the database really that big

                Many routers allow you to connect to them via a web browser. Probably there's a way to handle this with a Javascript program the router runs (I know nothing about Javascript and intend to remain ignorant of it) but it would be easiest if the router just supported timezones - and DD-WRT for instance already does at the OS level and a lot of commercial router software is based on that.

                1. garretmh

                  Re: Is the database really that big

                  Any browser IE 11 or newer includes basic JavaScript support for IANA time zones

                2. RichardBarrell

                  Re: Is the database really that big

                  FWIW, if you're prepared to have a little bit of JavaScript in the frontend, it's possible for a web application to have the backend work with only UTC times and the frontend display locally correct times, without needing a copy of tzinfo server-side. I have done it (in an application that already needed JS for other reasons anyway).

                  Of course that doesn't suffice for complicated things where you really do care about the local time zone in the backend. e.g. if I'm scheduling a thing to happen at 9am every day, I probably don't want it to suddenly start happening at 8am or 10am when DST flips over, so the backend will need tzinfo.

              2. doublelayer Silver badge

                Re: Is the database really that big

                The software the router runs all has to know about that. If you set up a filter, then:

                1. The interface must know your time zone so you set it at local time.

                2. The filter program, which is likely a different process, needs to know about your time zone.

                3. The log the user sees has to know about the time zone.

                Given that most of the routers out there are running something with a Linux core which can handle time zones and has sufficient storage to store the relatively small database, why not have the OS handle time zones like any software on a normal computer would do?

          2. doublelayer Silver badge

            Re: Is the database really that big

            "I suppose there might be a few things like thermostats which have local interaction with a clock involved, but... Have a "DST" toggle button?"

            No, please don't do that. Such things confuse a lot of people (I.E. which position should this switch be set to now? Was it set right the last time?). If it's smart enough to know what date and time zone it is, it can switch that automatically unless configured not to. Having to change a dumb clock is fine, but having to change something which is smarter and probably not obvious that it has a clock is just a pain. If we have to do DST (and we really don't), then the computer should do the adding and subtracting.

            1. Crypto Monad Silver badge

              Re: Is the database really that big

              ISTM that any "smart" (i.e. Internet-connected) device, could query a web service to get its timezone data. The location (country/state) could normally be determined from IP address, and overridden by the user if necessary.

              It could either be a shared service, or something provided by each manufacturer for their own devices. If the service stops responding, then stick with the last-downloaded info.

              Advantages:

              - No hard-coded database

              - No need to perform firmware updates when the location changes its timezone rules

              - Easier to support a single TZ service indefinitely, than providing ongoing firmware updates for all device models ever produced

              - Time zone data can be maintained in whatever granularity makes sense, without affecting device resources

              Disadvantages:

              - Privacy. But you already lost that battle as soon as the device makes any sort of call-home over the Internet.

              1. bombastic bob Silver badge
                Devil

                Re: Is the database really that big

                Simply downloading the TZ data for your time zone, during setup, would work just fine, with a micro- controller-based embedded device that has a simple web interface. The embedded device would then use the data to do its time conversions on its own internal clock and display the correct(ed) time.

                (for offline setup maybe a fallback system where you manually enter things like UTC offset and DST start/stop etc.)

                I've done some experiments with Arduino with a web interface. With some creativity, you could make it all fit in the NVRAM, though it's probably a LOT better if you use a device with larger than 32k for code space.

            2. John Robson Silver badge

              Re: Is the database really that big

              A slider that has one end labelled DST isn’t a complex interface, and it would only be needed on the few devices with a clock. My old thermostat (just about digital, but certainly not connected).

              (Apologies I did say toggle button, wasn’t what I was thinking)

              It’s only relevant on a device that does some time based switching, and displays a basic time based interface - old thermostats are the only example I could come up with (never had a cooker or microwave that knew what day it was).

              Anything using a web interface has a better way to configure stuff (use the web UI - import a snippet of the TZ dB when the user configures you (only need the forward data for this TZ after all).

              1. doublelayer Silver badge

                Re: Is the database really that big

                "A slider that has one end labelled DST isn’t a complex interface"

                I don't know about that. I remember distinctly a device which had time zone settings in two menus. The first required you to select your UTC offset. That for me was easy, but I doubt the general public who would also be using this device would automatically know that. The second: daylight saving time disable/enable. When I first saw that, I assumed that meant that I should select whether my country did DST. As far as I knew, my time zone contained some countries doing DST and some countries not, with all those observing it starting on the same date. I quickly realized how that was a stupid assumption, as there are time zones that don't have just two categories. I then assumed that the switch would change the clock by an hour, so I should just switch it when the clocks change. I tested it and it didn't.

                Only later did I discover that there was an NTP update running, and I was supposed to switch it whenever the clock changed then wait for NTP to get UTC again, reflect my switch,and update the clock accordingly. By the way, that's skipping the part for many non-developers who aren't paranoid about getting DST wrong (XKCD) and don't know whether "enable" means summer or winter. Those who get it wrong have the clock wrong by an hour all year long. Is a "select your location" thing really so tricky? I ended up disabling NTP and just remembering to change the clock.

          3. bombastic bob Silver badge
            Meh

            Re: Is the database really that big

            Why would anything embedded want anything other than UTC?

            In some cases you might have to deal with outside systems that need accurate time stamps. If those systems use local time and NOT UTC (UTC would be sensible, try telling THEM that) then the embedded device will have to "do things THEIR way" and get the time zone right because the existing system and customer base do things that way and they're big and you're not. Or something like that.

            So you provide a screen to use tz data to set the time zone just like you do when you set up a personal computer. On Linux it's not too hard, right? [I manually filtered North American time zones and stuck them in a drop-down combo box, one that's easy to change if it ever needs to, so the interface would not be unnecessarily cluttered with 100 time zones or something]

          4. HelpfulJohn

            Re: Is the database really that big

            My cooker has a clock that should, sometimes, display B.S.T. but to my knowledge never has. It has automatics such as a countdown alarm and settable cooking programmes so having the "correct local time" really should matter at least a little though realistically not so much as one would at first thought imagine.

            It never has had. In the unlikely event that I need to programme a meal, I would simply work out the B.S.T. to U.T.C. corrections. It's hardly rocket surgery.

            I'm not entirely sure whether the device counts as an "embedded system" or whether it is more in the nature of the relays that drive my washy-machine but with a clock added as a trigger. It's pre-Win-XP tech so I rather suspect the latter.

            Uhhm, I'm also fairly sure that the time displayed is not, in fact, G.M.T. nor any recognised time-zone as I have long ago forgotten how to set it. I really should rediscover this procedure.

    3. Anonymous Coward
      Anonymous Coward

      Is UCLA forcing the hand?

      Paul Eggert has argued that the changes will bring "equity" and be "fair" to countries such as Angola. When asked about why it is necessary to make these breaking changes now he has referred to private emails, outside forces and claims that it is "relatively urgent for us".

      I believe these posts from Eggert captures the political motivations behind his initiative:

      https://mm.icann.org/pipermail/tz/2021-September/030672.html

      https://mm.icann.org/pipermail/tz/2021-September/030721.html

      https://mm.icann.org/pipermail/tz/2021-September/030732.html

      https://mm.icann.org/pipermail/tz/2021-September/030740.html

      https://mm.icann.org/pipermail/tz/2021-September/030742.html

      I am left with the impression that Eggert is being forced by someone, possibly his employer at UCLA, to carry out these breaking changes while ignoring the concerns of people from Microsoft, Oracle, .NET, Java, PHP, Tcl and PostgreSQL.

      See https://mm.icann.org/pipermail/tz/2021-June/030194.html (thread)

      1. Brewster's Angle Grinder Silver badge

        Re: Is UCLA forcing the hand?

        Thanks for those.

        To summarise. "It looks a little bit racist to do for Europeans what we refuse to do for others. (Have separate timezones for countries.)" But we're refusing to mention the "R" word.

        1. Anonymous Coward
          Anonymous Coward

          Re: Is UCLA forcing the hand?

          Perhaps with the minor detail that those separate timezones exists because of decades of effort in documenting historical data (pre-1970). If I understand things correctly, Eggert has decided - in the name of "equity" - to deal with the situation by simply tossing out that historical data so he can get rid of those separate timezones. He argues that since he has already done this to smaller (African?) countries, it should be fair to do this to European countries.

          Plenty of people have asked him to reconsider as his actions will break existing systems, but he seems to be 100% committed to ignoring such pleas... because "equity".

          Eggert insists that this is not a political decision, but I disagree - this is a geo-political issue and the outcome should not be for Eggert to decide by himself.

          1. Anonymous Coward
            Anonymous Coward

            Re: Is UCLA forcing the hand?

            An American deciding this over the objections of Europeans - among others - does not, at first glance, seem to be a shining example of "equity"...

        2. Jan Ingvoldstad

          Re: Is UCLA forcing the hand?

          If there is an issue in non-European nations past, present or future being incorrectly bundled together, the obvious solution to me would be to fix the incorrect bundling.

          1. Strahd Ivarius Silver badge
            Mushroom

            Re: Is UCLA forcing the hand?

            there is always also the option of totally removing the countries from the map (see icon)

          2. AdamWill

            Re: Is UCLA forcing the hand?

            Jolly good. It's an open source project, so I take it you're volunteering to spend the next six months researching a couple hundred years of timezone history for the world outside of Europe. I look forward to the patch!

            1. Anonymous Coward
              Anonymous Coward

              Re: Is UCLA forcing the hand?

              I seem to remember once stumbling on a section of the timezone info where someone had gone to great lengths to define "london time" and "GMT" to take account of the various different positions of the Greenwich meridian in the 1700s and 1800s (it moved several times by upto a few metres each time as the methods for definiting it was refined by successive Astronomer Royals) and then preceded by the time as defined by a sundial somewhere which was considered to be the reference before then.

              N.b. this sort of change "by dictat" seems to be exactly the sort of thing that will spin off an activity to do it in the way it ought to have been done. Sounds like its time to fork time!

            2. John Savard

              Re: Is UCLA forcing the hand?

              Why can't someone from each of the countries outside of Europe research his or her own country's time zone history? A large-scale collaborative effort (think of Wikipedia) is more likely to produce a result than one person attempting a Herculean task.

              1. John G Imrie

                Re: Is UCLA forcing the hand?

                If you look at the raw data in the TZ file you will see acknowledgments of who provided which bit of historical data.

              2. Anonymous Coward
                Anonymous Coward

                Re: Is UCLA forcing the hand?

                My submission on some country's time zone history in March still has not been processed until now.

      2. bombastic bob Silver badge
        Coffee/keyboard

        Re: Is UCLA forcing the hand?

        "equity" "make tzdb fairer again". Blchggg... where's the pink liquid... (see icon)

        There's no crying in baseball... (yeah we all saw 'League of Their Own' right?)

        - and -

        There is NO POLITICS IN COMPUTING !!!

        what a ROTTEN way to swing a WRECKING BALL into a world-wide project to maintain a LIST OF TIME ZONES

  4. Anonymous Coward
    Anonymous Coward

    Oh ffs, is it really necessary to merge zones and delete pre-1970 changes? We're not running on mainframes with 64kwords of memory any more. Utterly pointless changes from an arsey developer who WONTFIX anything he's philosophically opposed to regardless of arguments or consensus to the contrary. Oslo isn't even in the fucking EU, it's a separate political entity with control of it's own timezone and could easily potentially diverge again in the future.

    1. A.P. Veening Silver badge

      And the EU is spread over at least four five time zones with Greece on one end and the Azores Cabo Verde on the other.

      1. katrinab Silver badge
        Meh

        Yes, but DST rules are the same throughout the EU - forward on last Sunday of March, back on last Sunday in October, both at 1am UTC.

        This may change soon, it is been due to change next year for about the last 5 years, one of these times it might actually happen, and if it does, it will change throughout the EU. Norway, UK, etc would need to make there own decisions about whether to follow the EU in making these changes.

        1. demon driver

          If I remember correctly, I think the European Parliament voted to abolish DST, but it was left to member states how to act upon it. Now the member states are stalled in discussions about which country will make which time, summer or winter time, permanent. It might just turn out to be easier to keep things as they are than to devise a plan which all member states can agree upon. Brexit with Ireland still in the EU hasn't made things easier, either...

        2. Anonymous Coward
          Anonymous Coward

          The UK will, no doubt, do exactly the opposite of what the EU do. It's due to "sovrinty, init?" - And to get them back for stealing all our lorry drivers.

      2. Anonymous Coward
        Anonymous Coward

        EU is spread over a few more timezones if you consider overseas France - eg French Guyana (according to wikipedia the location of the EUs largest national park), Tahiti (location for surfing in the 2024 Paris Olympics) and, at least for now, New Caledonia.

        1. A.P. Veening Silver badge

          True, but that spreads it over non-contiguous time zones.

        2. Somebody somewhere

          While Tahiti (French Polynesia) and New Caledpnia are part of France, they are technically outside of the EU.

          For instance, freedom of movement does not apply. EU citizen are treated as foreigners and need to obtain a work permit in New Caledonia, while (metropolitan) French don't.

      3. Dave559 Silver badge

        "And the EU is spread over at least five time zones with Greece on one end and Cabo Verde on the other."

        And parts of the EU spread even further around the world than that: France isn't just "metropolitan France", for example. In fact, perhaps that's the current "empire on which the sun never sets"? ;-D

        1. A.P. Veening Silver badge

          And parts of the EU spread even further around the world than that: France isn't just "metropolitan France", for example. In fact, perhaps that's the current "empire on which the sun never sets"? ;-D

          Meaning God doesn't trust those French in the dark either ;)

      4. Potemkine! Silver badge

        the EU is spread over at least four five time zones with Greece on one end and the Azores Cabo Verde on the other.

        Much more than that. Outermost Regions are part of the EU.

    2. Brewster's Angle Grinder Silver badge

      The Norwegians (and everybody else affected) should absolutely diverge to ensure their timezone is maintained. Drop DST for a year, or something.

  5. Greybearded old scrote Silver badge
    Thumb Down

    We need more like Linus

    This is the sort of "breaking userspace" change that used to break Linus' patience. Many of the sweary rants were directed at repeat offenders on that front.

    If others are relying on you, don't "move fast, break things." Use care and deliberation, don't honk off the folks downstream.

  6. W.S.Gosset

    Just another dissociated idiot

    "Optimising" according to a theoretical elegance in his head. Not oblivious to the world, just dismissing it ; angry at people not recognising their virtue. "Make a change! Make a difference! BE the difference!"

    Fork.

  7. disgruntled yank

    PACKRATDATA

    Not judgmental, are we?

  8. Gene Cash Silver badge
    FAIL

    Lennart Poettering would approve!

    This sort of mess is just up his alley.

    1. Robert Grant

      Re: Lennart Poettering would approve!

      "In practice this has been happening for years anyway."

    2. bombastic bob Silver badge
      Unhappy

      Re: Lennart Poettering would approve!

      And Sinofsky [and others] as well

  9. herman
    Facepalm

    Sounds like a Make Work project.

    1. Anonymous Coward
      Anonymous Coward

      FTFY: Sounds like a Make Woke project.

  10. Julz

    Hum

    ICANN strikes again.

    From Wiki:

    "ICANN took responsibility for the maintenance of the database on 14 October 2011. The full database and a description of current and future plans for its maintenance are available online from IANA".

    1. Twanky

      Re: Hum

      ICANN took responsibility for the maintenance of the database on 14 October 2011. The full database and a description of current and future plans for its maintenance are available online from IANA.

      Yes, but at what time on 14 October 2011?

      1. bombastic bob Silver badge
        Trollface

        Re: Hum

        UTC or local TZ?

      2. Ian 55

        Re: Hum

        Never mind that - what calendar?

  11. Whitter
    Coat

    Just think of the Atrologers!

    First time I've ever said that...

    1. disgruntled yank

      Re: Just think of the Atrologers!

      First time? Not even in regards to Libra Office?

    2. Allan George Dyer
      Paris Hilton

      Re: Just think of the Atrologers!

      @Whitter - And don't you wish you hadn't?

      What is an Atrologer anyway?

      1. Anonymous Coward
        Anonymous Coward

        Re: Just think of the Atrologers!

        A tz-rologer? Problem solved by assuming there was a typo in the original post, now the only thing needed is a suitable definition of a rologer.

  12. AVee

    Do we need two timezone databases?

    I kinda get what they want to do here, there are lots of 'different' timezones in tzdb which for a lot of purposes aren't different at all. I just recently had to write code handling just that. It was all about times in the future and needed to take time differences and daylight savings into account. And it simply was more complicated than needed because Europe/(Amsterdam/Berlin/Oslo/Paris/..) are considered different zones because things where different over 50 years ago. So I sure can see the case for merging zones which are identical right now.

    However, I can also see how there are perfectly valid uses which do need the historical differences. So perhaps we need two databases, one that is complete with all history for people who need it, and one with just the current data (or maybe just the last 5 years or so) for people that only need to deal with recent and/or future dates and times.

    1. Greybearded old scrote Silver badge

      Re: Do we need two timezone databases?

      Really?

      Time zones are insanely complicated because of myriad political (pronounced "stupid with a capital F") decisions. But adding more complication can't ever make things simpler.

      1. AVee

        Re: Do we need two timezone databases?

        I see the political issues with the current proposal which basically drops Oslo and keeps Berlin (I even agree with that being wrong). I also understand the desire to reduce the number of zones because so many of them have been functionally the same for a long time now. To me it seems that both of those can be satisfied by having two databases. The database with the 'recent' zones could be created by just merging all zones which have been identical in the last 5 years. A strict rule like that should go a long way to avoid the politics. It would also leave the current database intact, with all history in there so nobody needs to feel left out.

        But maybe I'm too optimistic about the politics involved, that's possible.

        1. Brewster's Angle Grinder Silver badge
          Terminator

          Don't mention the...

          Your wish is their command. Except the rule is timezones that are the same since 1970 are merged, and the second "database" is maintained in the source and available at the flick of a command-line switch to those who need it. (Me.) What they are trying to do is enforce that rule - with the consequence that 1940s Oslo now looks like Berlin...

          1. Jan Ingvoldstad

            Re: Don't mention the...

            Seems like most people have forgotten that 1981 is 40 years ago, not 50.

            Europe/Oslo had no DST until 1980, when DST started in early April, thereby divergent from Europe/Berlin, until the EEA coordinated from 1981.

            1. Lennart Sorensen

              Re: Don't mention the...

              Well turns out 1980 was also when Germany, Austria, Denmark, Sweden, and a bunch of others introduced DST. So unfortunately they do in fact match since 1970.

              1. Jan Ingvoldstad

                Re: Don't mention the...

                In 1980, Germany started DST on the last Sunday of March, while Norway started on April 6th.

                DST was standardized in the EEC as of 1981, and Norway (and, I assume, the rest of the EEA) joined.

                1. katrinab Silver badge

                  Re: Don't mention the...

                  Iceland is in the EEA and doesn't do DST. Probably because in winter there is very little daylight, and in summer, so much daylight, that there is no point.

                2. Jan Ingvoldstad

                  Re: Don't mention the...

                  In the interest of factual honesty, I seem to be mistaken here. (East, West, and reunited) Germany appears to have had the same deviations from the current DST regulations as Norway in 1980, and in 1981-1996.

            2. Robert Carnegie Silver badge

              Re: Don't mention the...

              I'm not clear on how this works in general, but BBC World Service radio (Europe anyway) broadcasts in English and in Greenwich Mean Time twelve months of the year. I suppose if you're halfway round the globe then converting that to your local time needs knowing how far away Greenwich is and whether you have local daylight saving, which you probably know, but it excuses you knowing whether it's daylight saving in Greenwich, because how would you.

              So in this sense at least, Greenwich Mean Time exists while London (except the BBC) is not using GMT.

          2. Anonymous Coward
            Anonymous Coward

            Re: Don't mention the...

            So, the UK will need its own entry since in 1970 the 3 year "all year BST" experiment was in progress!

            (I remember it being at primary school in what is now Cumbria then ... we went to school in pitch black during the winter, school was only ~1/2 mile away but along a busy road with no pavements so parents arranged rotas to take us by car etc and the habit of walkign children to school was lost)

            1. W.S.Gosset

              Re: Don't mention the...

              And another for WWII's Double Daylight Savings Time.

    2. Dan 55 Silver badge

      Re: Do we need two timezone databases?

      How about a new "modern name" column, and all the different timezones in CET could have "CET" as the modern name and would appear as one item in a user-facing timezone list. That's probably workable.

      But if the solution to your problem is two of something, then you usually end up with two problems later on.

      1. Dazed and Confused
        Trollface

        Re: Do we need two timezone databases?

        CET WET

        Reminds me of a conversation with the lab engineers of a certain Unix vendor back in the 80s. Can't remember how the conversation started but

        Me: Why do you call the timezone for the UK, WET

        LabEng: Coz that's what you call it

        Me: No we don't

        LabEng: you do

        Me: I live there I should know

        LabEng: Well what do you call it

        Me: GMT

        LabEng: that's not its name.

        Me: Well what do you call your timezone.

        LabEng: MST

        Me: What's the full TZ= variable setting?

        LabEng: sounding exasperated TZ=MST7MDT

        Me: And the 7 is?

        LabEng: still sounding exasperated the 7 hours after GMT

        Me: precisely, and where is the Greenwich in Greenwich Mean Time? Let's face it, we're not talking about the one in New Your are we.

        LabEng: Ah... So you actually use GMT time as your own time too

        Me: Errr Yes, well at least in winter, in the summer we have British Summer Time, which is just another phrase for "it's raining again"

        As the man page for spell used to warn

        Warning! the British spelling was also done by an American.

    3. Mike 16

      Re: Times in the future

      Taking DST into account? How the heck do you predict the setting for DST past the recess of the current legislature? They can change DST rules at the drop of a gavel, so "future" is far from guaranteed.

      Somehow reminds me of how (IIRC) MSFT finally patched Windows to recognize 2000 as a leap year in about November of 1999. The complaints that drove this patch were from financial firms that had to deal with dates in the future (like, loan payments).

      Time is tricky enough without politicians and programmers. We will have both until the dolphins take over.

      1. Twanky
        Facepalm

        Re: Times in the future

        ...and two databases.

        As many here will recall in 2007 the US changed their DST rules. They'd announced the change in 2005 but Microsoft didn't release updated timezone 'patches' until after the end of US DST in 2006. Effectively there were two timezone databases to consider: one before and one after the change.

        Calendar/diary entries (for example) that were made before the patches were applied were not automagically shifted to the correct time (though, to try to be fair, MS did release a tool to try to identify and fix the times of appointments). Added complications arose because external appointments might come from an already patched system to an un-patched system or vice-versa and then none, one, or both (or more, for large meetings) systems might be patched by the time of the appointment.

        I really don't think having two tz databases is a great idea. Different versions are bad enough.

        1. Twanky
          Black Helicopters

          Re: Times in the future

          I also remember that train and flight timetable boards were distinctly unreliable in Sydney when Aus decided to tinker with the start of DST (usually October) and have it start in August 2000 to avoid disrupting the Olympics. That went well...

          Icon: When the big hand is pointing straight up and one of the little hands is pointing somewhere between the four and the five then it's... difficult to work out what's going on. --->

  13. Primus Secundus Tertius

    Dates

    How about moving the international date line from the Pacific Ocean to the Atlantic? It could be much straighter, not dodging around hundreds of islands.

    1. A.P. Veening Silver badge

      Re: Dates

      Do you really want America to make good on its claim it is the future?

    2. Julz

      Re: Dates

      Apart from the British ones...

  14. poohbear

    Might as well... https://en.wikipedia.org/wiki/Swatch_Internet_Time

    1. Whiskers

      A drawback to having a single time zone for the whole planet, such as Swatch Internet Time, is that the date and day of the week will change during the working day in many longitudes (about half as a rough estimate).

      Imagine having to wait until tomorrow for lunch-time ...

      1. bombastic bob Silver badge
        Devil

        why we have time zones around the world

        yes, this goes back to the 1800s when time zones were invented. With time zones, people could still use a clock and the sun (and maybe a rooster) to determine when to wake up and do their daily work [mostly agrarian and support of agrarian work] and when to sleep, but ALSO the train schedules were synchronized well enough to allow the railroads to schedule use of single-track rail lines (and avoid train wrecks). It made so much sense the entire world adopted the idea.

        Besides, can you imagine how the TV schedules would be messed up if we were all on UTC? You'd still have "time zones" but they'd be based on when the morning shows and evening news comes on in your area...

        When i was in the Navy, if we deployed longer than a few days, on the sub we'd switch to "Zulu Time" and operate on UTC until we came into a scheduled port, at which point we'd switch to the local time zone. It avoids switching the logs around every time you cross into a new time zone. Meals and watch rotation was all time based and so it was done in a sensible way. On a sub there's no night or day but the meals change. That's how you know what "time of day" it is. And watch rotation often throws you into 18 hour days (6 on, 12 off), which makes things that much more "interesting".

        1. W.S.Gosset

          Re: why we have time zones around the world

          Yeah, timezones came about directly and simply to allow readable/useful timetables to be printed. Up till then, every town had its own time, set correctly. Now, every clock is wrong.

          Oxford still has its public clocks set to correct time. IIRC, 2 mins behind London/GMT. A lovely nod to history, and to eccentric boffinry precision.

    2. Anonymous Coward
      Anonymous Coward

      > What is GMT?

      > Greenwich Mean Time or GMT is the time displayed by the Shepherd Gate Clock at the Royal Observatory in Greenwich, London. When the sun is at its highest point exactly above the Prime Meridian, it is 12:00 noon at Greenwich.

      > GMT is is not affected by Daylight Saving Time (DST) clock changes.

      > The Greenwich Meridian (Prime Meridian or Longitude Zero degrees) is the reference point for every Time Zone in the world.

      > Every 15° longitude represents one hour's difference in time: (24 x 15 = 360, the degrees of a circle). You can work out the time at every location on earth if you know how many degrees it is east or west of Greenwich.

      The problematic database is not necessary. A simple GPS signal can be used to determine each locations actual time - no needless clumping involved.

      And Brittania's got a solid lock on the IP - the royalties will surpass those of North Sea oil, but they will last forever. Get me Boris on the phone! This is going to bigger than "what3words".

      1. Strahd Ivarius Silver badge

        Fortunately, UTC has replaced GMT, which is now relegated to the dustbin of history

        1. Anonymous Coward
          Anonymous Coward

          UTC vs GMT vs UT1 vs UT0 leads down a rabbit hole that leaves you singing an old song by Chicago.

          Once you've discovered that you don't know when you are, then go read up on things like WGS84 and discover that you also don't know *where* you are.

        2. John Brown (no body) Silver badge

          Not, UTC is a standard while GMT is a timezone very much still in use for at least half of the year in the UK, Portugal, Ireland, Canary Islands and Faroe Islands. :-)

      2. doublelayer Silver badge

        If we throw out daylight saving time, which we can and probably should. We also have to deal with the countries that decided to have fractional time zones, among them Australia (some states at UTC+9:30), India (UTC+05:30) Canada (one province at UTC-3:30) and the weirdest Nepal at UTC+5:45. Also China's insistence on using one time zone when they're big enough to need three, and it's not even the middle one. Here's what currently happens to the map when you use the time zones as they currently exist: https://xkcd.com/1799.

        1. Precordial thump Silver badge

          Aussies have AWCT (Australian Western Central Time, +08:45) as well. Another 15-minute offset from GMT, it applies only to Eucla, a spot on the map on the SA-WA border, to put it halfway between Perth and Adelaide, chronologically as well as geographically.

          Except when Adelaide is on ACDT. One country, seven time zones.

        2. Mike 16

          Throwing out DST

          @doublelayer

          IIRC the most recent DST battle in California was about getting rid of the yearly clock-setting festivals, which most people approved. Alas, major support was behind the notion of making DST year round. So kids could have the opportunity to walk to school in the dark much more of the year, and one might get a bit sleepy waiting for the feature at the drive-in movie to start. But shops and (especially) restaurants from extended "after work" hours.

          (Yes, I do live in a town small enough that many kids can, and do, walk to school. Yes, the school has more than one classroom)

          1. bombastic bob Silver badge
            Devil

            Re: Throwing out DST

            in 1973 the USA kept dailight savings time for an entire year. I walked to school. No problem.

            In 1974 and 1975 I went to a high school that had "split session" and Freshmen had school from 12:00 to 4:30 (or something like that). I walked home in the dark during the winter. No problem.

            Actually it was not THAT dark in either case. but as I recall, the cars had their headlights on.

            besides, most parents are like "helicopter parents" these days, and drive their kids to school. The local private school near my house has the expected traffic jams as the expected times because of it. Fortunately there's a way to drive around it if I ever need to.

        3. Anonymous Coward
          Anonymous Coward

          Hey, there's something missing from that map

          In years BC (before children) we went on a holiday to the Maldives and the island resort we were on had it's own timezone. Why? well who wants to get up in the morning when you're on your holidays.

      3. John Brown (no body) Silver badge

        "A simple GPS signal can be used to determine each locations actual time - no needless clumping involved."

        So, from London, you tell your mate in Bristol you'll phone at 12 noon tomorrow. He gets a bit pissed off when you phone 10 minutes early while he's still in a meeting. That's why "railway time" was invented :-)

        1. Whiskers

          According to GPS, the actual physical meridian marked on the ground at the Greenwich observatory (and by a big laser beam too), is wrong by more than 100 yards.

          1. herman

            Nope - it is the GPS that is wrong by 100 yards. The physical earth cannot be wrong. It is what it is.

            1. Whiskers

              "What it is" is somewhat arbitrary, depending on how certain terms are defined mathematically, what assumptions and measurements are used to determine the actual shape of the planet and of its gravity field, how accurate those measurements actually are, how many of those things things change over time, ... once the axis of the original transit telescope is too far away to touch, it's remarkably difficult to describe precisely where it (or anything else) actually is with respect to anywhere else on the planet.

            2. John Brown (no body) Silver badge

              FWIW, neither are wrong. The two were simply defined in different ways, which means there is currently a ~102 metre difference. Also, the original Greenwich one moves slightly due to the Earths crustal plates moving a bit over time.

        2. Anonymous Coward
          Anonymous Coward

          While not GPS, a couple of years ago I became slightly confused by the time when we were on holiday in the Algarve and spent a day visit the far eastern end we'd never been to. Driving up beside the river that marks the border between Portugal and Spain my phone and smartwatch weree continually flipping time by +/- 1 hour depending on whether the phone had connected to a Portugese or Spanish phone tower!

          1. David Nash Silver badge

            Spain should (geographically) be on the same time as Britain and Portugal anyway. I seem to remember hearing that they changed during Franco's time to show support for Hitler.

      4. MarkET

        Simple GPS signal?

        Is the most complex system of clocks. Think relativity and orbital velocity.

  15. Short Fat Bald Hairy Man

    Wow, just wow

    So we lose information? Brilliant. Is this how civilisations decline?

    1. Throatwarbler Mangrove Silver badge
      Stop

      Re: Wow, just wow

      No. Information is "lost" all the time. The question is, how relevant is that information to anyone who is not a tremendous time nerd?

    2. doublelayer Silver badge

      Re: Wow, just wow

      We didn't lose any information. A program stopped containing it. You can look up historical time information in many places. The question is whether the TZ database needs to contain all of what it currently contains. For the same reason, the TZ database won't correctly handle the calendar switch before the Gregorian became nearly universal, but if you want to see how each country did it at different times making a big mess, you can still look that up. People tracking historical events do this frequently. It's like asking whether a textbook should contain the full text of a historical speech--if it is decided that it's not needed for the educational experience, one can still look the speech up and read it elsewhere.

      1. Jan Ingvoldstad

        Re: Wow, just wow

        Well, some of us handle data from the past, and doing so consistently requires that essential libraries don’t suddenly change semantics radically.

        1. Richard 12 Silver badge

          Re: Wow, just wow

          1970 is very, very recent.

          Living memory.

          The DB is tiny. Really small.

          If you want to make a shorter set of "modern" timezones, then fine. Create them and give them explicit markers for their validity - for example, CET didn't exist prior to 1981.

          Don't screw around with existing historical data. Somebody is definitely using it.

        2. Short Fat Bald Hairy Man

          Re: Wow, just wow

          Exactly! The library is supposed to handle this. Now, no more.

          Date time programming is hell. This has just made it more hellish for that "some" set of programmers. If you want to deal with Oslo pre 1970s dates and time, cannot use this.

          And, as far as I can see, it is not even an actual problem, really!

  16. Dwarf

    David Olson Database

    If anyone wants the link - https://en.wikipedia.org/wiki/Tz_database

    Remarkable how simple it is. I tripped over this about 6 years ago when looking at sunrise and sunset calculations.

    I can't see any need to change it, the file is small and if it keeps it simple for consumers then why not.

    Trying to remember that region X got folded into region Y for no apparent reason doesn't help anyone, particularly if you need good Geography skills to figure things out, then it fails in its primary purpose. I'll take the hit of a couple of extra KB of data in the files thanks.

    .

    1. Ken Hagan Gold badge

      Re: David Olson Database

      Surely any half-decent compression scheme will eliminate the storage costs anyway, and an embedded system only needs to extract one time zone.

      Storm in a tea cup? This isn't even drizzle.

  17. Barry Rueger

    Relax...

    The other person in the house said "Who cares? Time is a purely artificial construct anyway."

    We need more Royal College of Art graduates in this debate...

    1. David Nash Silver badge
      Thumb Up

      Re: Relax...

      Time is an illustion, Lunchtime doubly so.

      DNA

  18. berntm

    Its pre-1996!

    "In a nutshell, put "Europe/Berlin" or "Europe/Oslo" with a pre-1970 date into the system, and out will come an answer. But the answer will be different for each option as there was a time when the two zones were different. However, as they've been the same for the past 50+ years, the proposal was to have "Europe/Oslo" simply be an alias of "Europe/Berlin" – meaning that Oslo's pre-1970 data would be effectively replaced by Berlin's."

    Nope. It's for pre-1996 dates. Before that, there may be differences. E.g. in 1983 when Germany changed from DST last Sunday in September, while Norway changed last Sunday in October.

  19. TimMaher Silver badge
    Thumb Down

    So that’s why

    My Rpi collection received a tz update recently.

    Not only is this change risky, for any number of legacy code reasons, it is also completely unnecessary.

    In recent years I have started recording ‘clock on the wall’ time in databases as well as the UTC and DST stuff in DATETIME columns as there is just too much of a fight going on in the various libraries that I have used.

    Ah well...

    1. TimMaher Silver badge
      Facepalm

      Re: So that’s why

      Just to add. Rpi have just received another tz update today.

  20. MarkET

    Too much time on their hands

    Leave the zoning to reflect history. It's a quarter past the third epoch...

    500KB database - when I were lad it were luxury to a have a Kb to share amongst 16 users...

  21. sreynolds

    I thought that the merge started taking place in 1939....

    Starting with the merging of the Warsaw and Berlin timezones.

    1. Short Fat Bald Hairy Man
      Coat

      Re: I thought that the merge started taking place in 1939....

      Surely you mean Warschau and Berlin?

      1. A.P. Veening Silver badge

        Re: I thought that the merge started taking place in 1939....

        No, Warszawa and Berlin.

  22. AdamT
    Joke

    Actually ....

    ... why don't we do away with timezones altogether? We all (*) have a device that knows _exactly_ where we are so could easily calculate a precise local time for you. Then all we have to do is indicate exactly where the event is due to occur at its local time and then everyone knows exactly when too!

    So bus/train timetables would factor in the position of the stop/station and google maps route finding would know where you are starting from (and what time it is there) and compare that with the place you are going (and work out what time it is there), etc., etc. ...

    There might be a few minor teething problems but I'm sure we could make this work!

    It would have a couple of advantages of spreading traffic and power requirements out a bit as depending on which side of the country you are, you would be doing things at a slightly different UTC time compared to the other side.

    This is a great idea! What could possibly go wrong?

    (*) well, many of us and a rapidly increasing proportion of the human race.

  23. Miko

    Multiplying the problem

    Simplifying timezone database handling by introducing a compile time option to build a different database, one for normal use and one for historians that need actual accuracy?

    What genius - now there are two databases to maintain! Ok, it's not so bad - you just have to run the full test suite twice, as well as making sure to have test cases that separate the differences. Uh... there *are* suitably complete test suites for something as important as this, yes? Especially with the sources obviously complicated by global compile flags that change the behaviour all over the place, and with the project goal of merging some of the timezones apparently touching quite old stuff with most every release, the expected results will also change with every release?

  24. Henry Wertz 1 Gold badge

    good move

    good move. Truly, this is a microoptimization (size reduction is low, and time to look up a timezone would be unaffected essentially... maybe even increased if looking up a symlink, following that symlink and opening resulting file was any slower than opening file directly.) I'd do it if nobody objected. But they are objecting, so why bother?

    For ease on the time zone administrators, just add a control file and script to saying which timezones are equivalent post-1970 so you can update the post-1970 for Berlin and the script can copy the post-1970 info to Oslo etc., so users have their seperate files but administrators burden is still lowered.

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