Hello. Guy Harris wrote in <19E9510C-884F-448F-8818-27C7DEB777CC@sonic.net>: |On Jun 3, 2021, at 12:41 PM, Steffen Nurpmeso via tz <tz@iana.org> wrote: |> Derick Rethans wrote in |> <alpine.DEB.2.23.453.2106031721460.2842@singlemalt.home.derickrethans.nl\ ... |>> FWIW, the issue here isn't about the naming of zones. It is about |>> removing historical data of one country, and replacing it by the |>> historical data from a different country. |> |> You only have a string, either from $TZ or some direct user |> selection. You link this string to a set of rules. |> It happens that if you move the mask of the rules back and forth, |> the number of paths through the set of rules grows or shrinks. |> As long as you can link name->rules, and, at the time the data is |> packaged, rules->name, everything is fine, is it? |> I have no idea how one could end up with Europe/Berlin when the |> initial TZ was Europe/Stockholm, really. (I have not looked into |> that for now quite a lot of years, too, however. But as i recall |> you have by-zone begin/end tuples into the packed data.) | |You have the string Europe/Stockholm. | |Prior to Paul's change, it referred to a tzdb region with the lines | |Zone Europe/Stockholm 1:12:12 - LMT 1879 Jan 1 | 1:00:14 - SET 1900 Jan 1 # Swedish Time | 1:00 - CET 1916 May 14 23:00 | 1:00 1:00 CEST 1916 Oct 1 1:00 | 1:00 - CET 1980 | 1:00 EU CE%sT | |After Paul's change, it's an alias for Europe/Berlin: | |Link Europe/Berlin Europe/Stockholm | |which is a tzdb region with the lines | |Zone Europe/Berlin 0:53:28 - LMT 1893 Apr | 1:00 C-Eur CE%sT 1945 May 24 2:00 | 1:00 SovietZone CE%sT 1946 | 1:00 Germany CE%sT 1980 | 1:00 EU CE%sT | |Post-1980, they're the same. I skip the rest of your explanation. Thank you for going all that way, but it was not meant "that" literally. So i have fetched myself a copy of the repository again, and i am thankful that the data as such, including the comments, is still there. It was what thrilled me so much over two decades ago when i first encountered the data, i was browsing in it for long hours. I did not know by then that behind the shiny dickeys of many entries there was nothing but hot air. I think tz is fantastic. I would not do it like this myself. I deem the data important, and i do not want to look into "backzone" after reading for example "europe" just to see if i missed something. I would rather change the extraction tools than the data itself. Also i think if i were to draw a line, where the epoch seems reasonable for C programming interfaces based upon time_t, then history cannot go further back. If i were to provide access to date and time before the epoch, however, available data should be included. I have not looked at PHP nor JAVA for twenty years, and never at NodeJS, but if these interfaces provide access to date and time outside the scope of the standardized C interfaces, then they surely parse the data and create databases on their own. This is what i did; unfortunately my code was neither bug free nor accounted for negative DST adjustments, to be honest. Today i think i would just extract data out of the compiled TZif files. As long as one can download a tarball and get away with a very portable "make PACKRATDATA=backzone zones" to have access to readily prepared full history, i would be satisfied, being happy to be able to get data from somewhere at all! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)