[tz] Ecuador time zone list

[Steffen Nurpmeso]

Paul Eggert wrote in
 <4ca13b77-e1d9-ff01-ebc1-4d8241789a94 at 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 at 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)