[tz] [PROPOSED] Merge timezones that are alike since 1970

[Steffen Nurpmeso]

Hello.

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!

--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)