[tz] Preparing to fork tzdb

[Steffen Nurpmeso]

Watson Ladd wrote in
 <CAN2QdAE8RdE0ynaTVi4WZ4F5PGDEMoxr-A6z_g89VtCsEZ632g at mail.gmail.com>:
 |On Tue, Sep 21, 2021 at 3:42 PM dpatte <dpatte at relativedata.com> wrote:
 ...
 |ISO countries doesn't solve some of the thorny political issues,
 |because ISO codes don't take a position on boundary disputes or naming
 |disputes. E.g. Crimea. When the invasion happened, the civil time in

You mean the russian majority living in the majority of the land
invaded the land it is living on for long?  Just to get it right.
Since NATO will move onward to the east (do not mind a possibly
existing contract, as we only fullfill wishes of the people living
there), i will surely soon be able to have a look myself.

 |the region occupied changed. That means a new zone entry needed to be
 |created. I don't know how defering to ISO resolves the naming of that
 |one.
 |
 |The other example would be Palestine. Regardless of what ISO decides,
 |the time in Palestine is what it is, and is different from Israel in
 |funny ways, and the territories that have gone back and forth have
 |gone back and forth and thus need new entries.

Well not much longer and that problem was overcome by enforced
exodus for many parts.  If the sun rises over the walls and the
razor wire, they surely know it is daytime, and it is time to go
and work on the fields they do not own.  Maybe what you meant.

 |What ISO countries do solve is the vanity issues of people wanting
 |timezones with their local big cities in them appearing in a list,
 |even if the timezone is the same as one in another country.

But let aside that radical left wing political targeted drone
killing, as we do not want another cold war, didn't the last
discussion came to the conclusion that all you need to get back to
original state is a slightly adjusted command line when building
the data?  Wasn't this true?  I mean here at [9296ea527d] i still
see

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

in backzone.  If i understood right TZ went for long the road to
actually go Epoch aka 1970 for the data, without requiring @0 at
build time.  It may even have been me who said something some
years ago, but over the years this free time work progressed
without anyone really complaining.  Any i came to the conclusion
this is maybe right, normal ISO C or POSIX time will not really
work before this, so you need specific software to do it "better",
and then you can very well compile your own database using the
rules which still exist in the TZ database, yet only in backzone.
My main concern was the splitting, ugly for human consumption,
when reading comments etc., but for software it really should not
matter.  (I personally would no longer use the source files, but
surely go and parse the now standardized binary files.)
So please let me wonder why software packages which seem to ship
copies of TZ releases in their sources do not simply use the data
available as a whole, as if the other backzone data would not be
worth it?

I personally think that it will be very hard to find a maintainer
equally destined and sophisticated.  I learned better awk as of
Kernighan by reading TZ script files.  I am total contra.

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