[tz] [PROPOSED] Merge timezones that are alike since 1970
steffen at sdaoden.eu
Sat Jun 5 17:33:12 UTC 2021
Guy Harris wrote in
<19E9510C-884F-448F-8818-27C7DEB777CC at sonic.net>:
|On Jun 3, 2021, at 12:41 PM, Steffen Nurpmeso via tz <tz at iana.org> wrote:
|> Derick Rethans wrote in
|> <alpine.DEB.2.23.453.2106031721460.2842 at 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!
|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)
More information about the tz