Paul Eggert wrote in <4ca13b77-e1d9-ff01-ebc1-4d8241789a94@cs.ucla.edu>: |Thanks for taking a look at it. The first patch is OK now that we've |worked around nawk's bugs, so I installed it (albeit with a different |URL). The other two patches have problems, though. They assume that |zone1970.tab and zone.tab are the only two possibilities, but a primary |reason for -t option is to let users choose other possibilities of their |own design. It is in sofar an improvement as any user gets an insight on what is, actually, going on. (Without reading the IANA TZ DB file theory.html.) Yes, it reflects my personal preference from including backzone always, but then again The default zone1970 partitions the world into timezones whose clocks all agree about timestamps that occur after 1970-01-01 00:00:00 UTC, so for ( example asking for the location Laos in the area Asia will answer Asia/Bangkok, since this timezone correctly represents the clocks of Laos ) since 1970-01-01. If ZONETYPE is zone, a country based answer will be given, in this case Asia/Vientiane. TZ DB build-time decisions decide whether timezones share pre-1970 clock data or not: if not the above ZONETYPE zone answer is an alias for the timezone Asia/Bangkok. Pre-1970 clock data is often not reliable. reflects the situation quite good i think. Text in parenthesis is too lengthy. To me plain: any user who actually is about to use the shell-level tzselect(8) for TZ selection purposes instead of some graphical interface that, much more or less, hides the political TZ ID problems that make for the most traffic. She runs into the political TZ ID problems. Wants to see Asia/Vientiane. Should know that pre-1970 data likely is _not_ Asia/Vientiane. Eh. Imho "let users choose ... of their own design" is a bit too nitpicking, since the script enforces data at a specific location, or invocations like AWK=nawk TZDIR=/usr/share/zoneinfo bash tzselect.ksh so that is very sophisticated.. is it? |So the second patch needs to be more generic, and not say that there are |just two *.tab files; it also needs to say that the -t option is Adding "ZONETYPE can be any other additionally installed timezone description" would meet these requirements of yours? |experimental. I suppose it also needs to document the current *.tab file |format. These sounds a bit biased to me. But zone.tab and zone1970.tab are serious data collections, yet one reflects merged zones since 1970, the other not. Not that many other possibilities are thinkable, except automatically generated ones that reflect 1:1 the installed variant, which may be an alias to either, but also something with a different clock cut-off. The latter was beyond my intent. |And the third patch goes in the wrong direction, as it hardwires the |assumption that 'zone1970.tab' and 'zone.tab' are the only two choices |and it outputs something cryptic and unactionable to boot. If we're Yes it was a hack. I have to admit i stopped because (a) it was late and (b) my gut feeling told me that you will say something like this regardless of what the outcome is, so putting more than 1.5 hours into this i refrained from doing. But the hack already shows the intent i had in mind, at least with the given "Laos" example, you go with the one zone and get a hint on what the other variant would have shown. It could be improved. |going to change tzselect in this area perhaps it would be better for |tzselect to act just as now, but if the user says "no" at the end then |give the user an option of trying again with the other *.tab files. By re-execing $0 with "the other" -t variant. But only as an additional option to Yes and No. --End of <4ca13b77-e1d9-ff01-ebc1-4d8241789a94@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)