[tz] timezone Verschlimmbesserung

Steffen Nurpmeso steffen at sdaoden.eu
Tue Oct 5 22:38:30 UTC 2021


Paul Eggert wrote in
 <d23f4a05-b5c4-d592-900c-b7ea5bbbfea0 at cs.ucla.edu>:
 |On 10/4/21 12:59 PM, Steffen Nurpmeso via tz wrote:
 |> (It would surely be doable to use tooling to automatically unite
 |> all zones which are identical post-1970, maybe give that an
 |> auto-generated name, and make all actual TZIDs which point to that
 |> data links automatically.)
 |I wrote such a tool to generate the May proposal, except that I didn't 
 |invent new names as I thought that would entail unnecessary complexity 
 |and confusion. It was kind of a hack, though, and not worth publishing.

It would also introduce nothing but harm on operating systems
/ filesystems which do not support links.  (Unless everything
would be organized totally different, which surely is a no-go for
IANA TZ.)  Yes.

 |> What really bugs me with the current post-1970-matters rule is
 |> that the "ZFLAGS='-r @0'" option is neither default nor
 |> prominently documented.
 |Making it the default would be a big lift, as people have expressed 
 |concern about churn in pre-1970 data. In hindsight perhaps we should 
 |have omitted pre-1970 data from the start (it sure would have saved me a 
 |lot of ill-spent time ...) but the backward-compatibility concerns do 
 |exist even if they're perhaps overblown.

I am still thrilled by the collected knowledge, and i am happy
that the thread has settled.  But i personally see no difference
in between the value of Europe/Copenhagen on the one hand, and
Asia/Vientiane or /Phnom_Penh on the other.

Your argument seems a bit fishy though given the post-1970
direction of the last years.  And yes, it is possible to use
a negative time_t regulary on the systems i have tried.
Death has taken a toll on those people who can be truly fooled
when they use date(1) to look up the date of their birth, though.

 |> Also that tzselect(8) gives the name of the actually really used
 |> zone instead of the name that was used
 |Could you explain more about this issue? I don't see how a "name that 
 |was used" is involved here. When a user starts up tzselect, there is no 
 |name yet. tzselect is supposed to let you choose a name de novo.
 |Perhaps you could show a sample tzselect session and explain where it 
 |goes wrong?

Of course.  Now that Europe/Copenhagen has been reverted i take
the example from above.

  #?0|kent:tz.git$ tzselect
  4) Asia [...]
  #? 4
  Please select a country whose clocks agree with yours.
  2) Antarctica              9) Cambodia [...]
  #? 9

  The following information has been given:

          Indochina (most areas)

  Therefore TZ='Asia/Bangkok' will be used.
  Is the above information OK?
  1) Yes
  2) No
  #? 1

  You can make this change permanent for yourself by appending the line
          TZ='Asia/Bangkok'; export TZ
  to the file '.profile' in your home directory; then log out and log in again.

  Here is that TZ value again, this time on standard output so that you
  can use the /usr/bin/tzselect command in shell scripts:

The announced nature of TZIDs are so the name of a dataset is ok,
but since "Link"s are stable and do work as such

  #?0|kent:tz.git$ TZ=Asia/Bangkok date
  Wed Oct  6 04:07:51 +07 2021
  #?0|kent:tz.git$ TZ=Asia/Phnom_Penh date
  Wed Oct  6 04:07:53 +07 2021

i would simply output the name of the link, maybe like so

  The following information has been given:
  Therefore TZ='Asia/Phnomh_Penh' will be used.
  It is a link pointing to the dataset TZ='Asia/Bangkok'.

Do not treat this too seriously.
The problem is that tzselect(8) uses nifty information linking of
and in between zone1970.tab and iso3166.tab, and in particular
The problem with the land of the thousand elephants etc. was among
the first changes in 2014-07.

It could only be changed (without additional data files / code
changes) by adjusting zone1970.tab to no longer join multiple
country-codes per line.  The datasets could still be shared, but
of course it is a maintenance burden as the comment field must be
identical.  Or some kind of "link" had to be understood also in
zone1970.tab, so that the name is retained, but the dataset can be
targeted nonetheless.  This could require multi-pass, then.

.... But, ach.  Forget it, i really would not do it like you do :)
It is really neat and .. it is really, really neat. :)  (I was
just wondering shortly about not using (^|,)X(,|$) for the
country-code regular expression, but it seems to work for all of
ISO 3166, so why bother?  I think.)  But i would use zone.tab as
it was back in 2014.  From this short glance i cannot see how it
would hurt the unsharing process.

It is just, you know, renaming the master branch to main
explicitly is hard to get in line with beating Buddhists like
that, just in case they would feel equally hurt like our Danish
dynamite friend did.  Of course the intention is understood.  They
also do not seem to bother the slicing.
I think maintaining the TZ DB is not an easy task.

 |As for the importance of astrological use of the tzdb main entries - 
 |tzdb has never been remotely adequate for pre-1970 timestamps, and I see 
 |no movement on the horizon to fix this. I have asked an astrologer or 
 |two for help on this topic with no results, not that I expected any; any 
 |effort in this area would have to be huge to get decent coverage.
 |Here's one way to think about it. After about 40 years of volunteer 
 |work, we have reasonable coverage for casting horoscopes for people aged 
 |50 or less. On current trends we can solve the problem of casting 
 |horoscopes for living persons, simply by doing nothing for the next 40 
 |years or so. Perhaps that's not ideal for astrologers, but it's pretty 
 |good bang for the buck.

(This was for Alois Treindl.  You had written his surename wrong
in a comment in the patch you posted last / a few hours ago.)

 --End of <d23f4a05-b5c4-d592-900c-b7ea5bbbfea0 at cs.ucla.edu>

|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 mailing list