Issue with "April" in northamerica file also breaks Elixir tzdata lib updater (":tzdata_release_updater terminating..."), a dependency of timex
Just wanted to add to the list of libraries impacted by this issue. tzdata is a dependency of the timex library, one of the most popular in the elixir ecosystem. A 2024c release with the fix would be much appreciated. Best regards, Greg McDonald
On 2024-09-09 11:57, greg--- via tz wrote:
Just wanted to add to the list of libraries impacted by this issue. tzdata is a dependency of the timex library, one of the most popular in the elixir ecosystem.
How is timex itself affected? As I understand it, timex reads TZif files and so doesn't need to parse strings like "April" that appear in .zi files but not in TZif files. So, like all TZif readers it should be unaffected by the "April" vs "Apr" vs "Ap" glitch.
Hi Paul. Good question. I had to dig around a bit but here's what I found. timex may read TZif files in trying to determine the local timezone of the machine. However, it also has a dependency on the tzdata library for its Tzdata.TimeZoneDatabase and a few other methods (such as checking whether specified timezones exist). Unless configured otherwise, the tzdata library will check on start up and then once a day whether https://data.iana.org/time-zones/tzdata-latest.tar.gz is different from its local copy of the TZ data. If it is, then it builds a new internal representation of the data; it is this operation that requires parsing the rules, etc.. All that being said, a new version of tzdata (1.1.2) was just released that updates the tz data bundled with the library to 2024b AND fixes the parsing of the months to accept "April", "February", etc..
On 2024-09-11 12:16, greg--- via tz wrote:
Unless configured otherwise, the tzdata library will check on start up and then once a day whetherhttps://data.iana.org/time-zones/tzdata-latest.tar.gz is different from its local copy of the TZ data.
OK, so it's not Elixir's timex package; it's Elixir's tzdata package. This brings up a couple of issues. First, Elixir apps should not constantly download from data.iana.org as it's not intended to be hammered on by every computer on the planet. To fix this, Elixir tzdata should be accessing a downstream copy or copies. And once it does that, this would address the second problem, which is that if there's a compatibility glitch between the Elixir tzdata code and TZDB, such as what occurred with TZDB 2024b, these glitches can be fixed in that downstream copy or copies without waiting for the next TZDB release. I filed a bug report for these two issues here: https://github.com/lau/tzdata/issues/149
This reminds me of the controversy and eventual abandonment of leap seconds. Leap seconds were invented over half a century ago and always had clear, well-defined rules governing how they were implemented and when they should occur. Despite this, they were almost universally cited as a source of paralyzing confusion, even by experts, and even though far harder problems are solved every day by both software and human decision-makers. In the end it was decided to just do away with them¹ and let the clock fall arbitrarily far out of step with the planet. “Names in tzdb can be abbreviated, or not” may be clearly defined and obvious to all (or maybe not so obvious), but if implementers decide not to read the spec and just go with whatever today’s data file has, their code will break when something different happens, just like a minute that lasts 61 seconds. They will declare the new data to be broken and demand that it be fixed to match the implementations, not the other way around. That is what is happening today. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org ¹ You don’t honestly believe that tale about declaring a “leap minute” or “leap hour” a hundred or so years from now, do you?
On 9/9/24 14:18, Doug Ewell via tz wrote:
... In the end it was decided to just do away with them¹ and let the clock fall arbitrarily far out of step with the planet. .
That isn't necessarily harmful. People will simply adjust their hours of activity to match the daylight as they did four centuries ago when clocks were advanced six hours. (Ref: Matthew 20:1-16 KJV vs. NIV.) They didn't start going to work at midnight. Likewise, the proposed perennial DST is bound do be ineffective. In time, days will begin at sunset, agreeing with various traditions. But is this official? (it says bipm): <https://www.bipm.org/en/cgpm-2022/resolution-4> o propose a new maximum value for the difference (UT1-UTC) that will ensure the continuity of UTC for at least a century, o prepare a plan to implement by, or before, 2035 the proposed new maximum value for the difference (UT1-UTC), If so, they're kicking the can down the road. -- gil
Paul Gilmartin wrote:
But is this official? (it says bipm): <https://www.bipm.org/en/cgpm-2022/resolution-4> o propose a new maximum value for the difference (UT1-UTC) that will ensure the continuity of UTC for at least a century, o prepare a plan to implement by, or before, 2035 the proposed new maximum value for the difference (UT1-UTC),
If so, they're kicking the can down the road.
That will never happen, at least during the tenure (and probably the lifetimes) of the current BIPM members, by design. Adding (or subtracting) a larger block of time at once, say a minute or more, would be far more disruptive than shifting one second at a time, and I’m sure they know it. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
participants (4)
-
Doug Ewell -
greg＠rumandcode.io -
Paul Eggert -
Paul Gilmartin