Hello. Paul Eggert wrote in <d23f4a05-b5c4-d592-900c-b7ea5bbbfea0@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: Cambodia 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: Asia/Bangkok 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 zone1970.tab. 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@cs.ucla.edu> --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)