1. 47
  1. 31

    Following up on the article, I found an interesting comment debating it in a nuanced-sounding way on the orange site.

    1. 8

      Unfortunately, he is currently ignoring all objections to an action only he seems intent on making to solve an invented problem that only he sees as important.

      I’ve been following the thread(s) and this is a horrible exaggeration at best. Making it seem like Prof. Eggert is going at it alone and claiming that these are issues only important to him is a blatant misrepresentation of the facts.

      There have been a lot of fair points made from both directions, but at the same time more than a few of the loud opponents have demonstrated that they do not know nearly as much as they think they do, and have resorted to throwing tantrums when they don’t get their way.

      What’s more is the over-exaggeration of how many people are actually opposed to these changes in principle (and can actually string together a coherent reason why!). It seems that once the drama kicked off, all sorts of people came out from the woodwork for no other reason than to make noise.

      Paul Eggert has put in a tremendous amount of unpaid / thankless time and effort into maintaining this project, and has generally been a decent steward in that regard.

      Stay tuned as I try and work out how best to resolve this completely unecessary drama.

      I can’t take this seriously. I don’t even know what to say to that.

      1. 7

        I hope that someone writes a response to balance this because this seems to contain some exaggeration. For example:

        In other words, it will be impossible for a Joda-Time user to hold the ID “Europe/Oslo” in memory.

        That’s false, because the library could keep both the requested and the database IDs available to the user. There’s no technical reason the GetID has to change.

        1. 7

          Not to mention this aside:

          (Technically, the data has moved, not been deleted. But the file containing the moved data is never normally used by downstream systems, thus to all intents and purposes it has been deleted.)

          I don’t really see how this is an insurmountable problem to address.

        2. 7

          Many of these changes, including all of the ones specifically complained about here, were already reverted earlier today. However, it appears the long-term plan is still to ‘level down’ the database.

          1. 6

            From my reading of the changes this seems more like a problem with how JodaTime deals with the changes than the actual changes themselves, and, if this were done without warning I would understand the author’s complaints but AIUI these changes have been contemplated and publicised for a while now.

            1. 9

              Yep!

              Technically, the data has moved, not been deleted. But the file containing the moved data is never normally used by downstream systems, thus to all intents and purposes it has been deleted.

              So the data is still there, but he’s just going to act like it’s completely vanished because the place it’s moved to is … a file he previously didn’t use.

            2. 5

              This post is an excellent example of how to not foster cooperation in the open source community.

              Stay tuned as I try and work out how best to resolve this completely unecessary drama.

              Unnecessary indeed. Check your tone and start over.

              1. 4

                One note / useful tip: the article mentions Reykjavik may be affected. Not just bad for Iceland; the Reykjavik time zone is a good choice if you want UTC but whatever software you’re using doesn’t understand a non-geographic timezone like UTC. Iceland has been UTC+0:00 without daylight savings time since 1967. I’d be a little sad if this option disappeared from software.

                Looking at the patches it looks like Reykjavik time will be listed as an alias with Africa/Abidjan. Côte d’Ivoire apparently hasn’t had DST since 1912.

                1. 5

                  the Reykjavik time zone is a good choice if you want UTC but whatever software you’re using doesn’t understand a non-geographic timezone like UTC.

                  What horrible software is this?

                  We can’t rely on Iceland never instituting DST, so our software shouldn’t either.

                  The same goes to Africa/Abidjan too, but at least there there’s no geographical reason to use DST. However, if Côte d’Ivoire develops significant economic ties with Europe it could conceivably implement DST to “track” timezones there.

                  1. 2

                    What horrible software is this?

                    I haven’t checked lately, but a few years ago I had my Chromebook and MacBook running on Iceland time because you weren’t allowed to set your user time to UTC (the system time was in UTC, not the user time).

                    (Edit: I looked this up and can confirm that on a recent version of macOS UTC - United Kingdom is available when typed into the timezone picker).

                    I changed it back because some sites (specifically Yelp) checked whether a store was open based on browser time, not necessarily the time at the store’s location. This meant that every store I looked at was “closed” during normal business hours, since Yelp was trying to determine if a store in California was open or not using Iceland time.

                    1. 1

                      Wow, just wow (that linked article, and also the uncertainty involved in tying “UTC” to a specific location).

                      Here’s a discussion using the command line, the discussion is also confused https://gist.github.com/nick-desteffen/1126771

                      (Because I’ve recently messed around with this on a systemd-enabled Linux, you should use timedatectl there, not directly symlink to /etc/localtime as in the example).

                      At least on Windows 10, you do get the bare “UTC” option, no confusion as to location.

                  2. 1

                    Africa/Abidjan satisfies both of those conditions, which has never had DST

                    1. 2

                      Thanks, and apologies; I think you responded to an earlier version of my comment before I figured out Abidjan would work.

                      I combed through the whole database and here’s all the options for modern UTC-like timezones: Africa/Abidjan, Africa/Bissau, Africa/Monrovia, Africa/Sao_Tome, Atlantic/Reykjavik, America/Danmarkshavn.

                      1. 3

                        A lot of zones already link to Africa/Abidjan: Africa/Bamako (Mali), Africa/Banjul (Gambia), Africa/Conakry (Guinea), Africa/Dakar (Senegal), Africa/Freetown (Sierra Leone), Africa/Lome (Togo), Africa/Nouakchott (Mauritania), Africa/Ouagadougou (Burkina Faso), Africa/Timbuktu (Mali). So presumably that’s why it was chosen. I don’t know why it was chosen as the target in the first place, but it seems like it’s been like this for a number of years, a lot of changes were made in 2014.

                        Similarly, a lot of zones already link to Africa/Lagos (UTC +1, “West Africa time”), Africa/Maputo (UTC +2, “Central Africa Time”) and Africa/Nairobi (UTC +3). All of Africa has 20 timezones in the current database (excluding aliases) for 56 regions, all with various real differences (DST, changed after 1970). The only linking being done for Europe now is the various British crown dependencies (Jersey etc.) to Europe/London and countries of former Yugoslavia linking to Europe/Belgrade, as well as some other minor things (e.g. Europe/Liechtenstein → Europe/Zurich).

                        For users nothing changes. You can still keep using Atlantic/Reykjavik if you want. It’s just an internal linking thing that happens, and the only area where it really exposes if you want times before 1970, in which case you need the full TZ database. It’s really not a big deal.

                        If people in the most ethnically sensitive part of Europe with literal genocides not all that long ago can avoid throwing a hissy fit over the internal structuring of some database then surely some bloke from London can…

                        1. 1

                          I noticed your edit right after I submitted my comment haha. Left it there anyways :)

                    2. 3

                      Here is the thread on the TZinfo mailing list where the author of the post proposes forking the database

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

                      1. -2

                        I posted this on reddit and surprisingly I wasn’t downvoted. ;)