[tz] Tzdb and the Sunshine Protection Act

[Robert Elz]

    Date:        Fri, 3 Mar 2023 16:38:48 -0800
    From:        Paul Eggert <eggert at cs.ucla.edu>
    Message-ID:  <53ba0709-0cfa-8859-8021-6b91909a9b62 at cs.ucla.edu>

  | That's not strictly necessary, as the RFC specifies the POSIX version, 
  | so even if POSIX comes out with a new version the RFC is still valid.

Technically yes, but it is much harder to acquire access to old versions
of POSIX standards than it is old RFCs, most people will just give up
when all they find is the current one (whichever that is).

  | > What kind?   I doubt that anything other than tzset() and related
  | > stuff ever parses a TZ string contents,

  | There's a partial list at 
  | <https://data.iana.org/time-zones/tz-link.html#TZif>.

Oh, sorry, that's what I meant by "tzset() and related stuff", obviously
anything doing localtime() or its equivalent in some other language or
system is going to have to deal with it.

I was asking about any applications that are not implementations of that
functionality - things that might not simply get updated if the TZif file
format, were to alter -- hence the possible example of a program which would
parse TZ and explain in natural language (or perhaps just something less
baroque than the POSIX TZ string rule format) what it all means.

  | I see uses for these POSIX TZ strings, even with tzcode and tzdata. 
  | Here's a scenario: your government abruptly changed the DST rules and 
  | you don't have access to the network (or perhaps your distributor hasn't 
  | updated its copy of tzdata yet) and so you can't get the latest tzdata 
  | easily.

Frankly, that would be horrible advice to give someone.   Anyone doing
that is going to change the interpretation of all previous recorded
timestamps to match the new rules.    That absurd behaviour (which I'm
sure you're well aware of) is one of the reasons those POSIX TZ strings
are useless.   In this case they're even worse than usual, where
normally the rules aren't changing for long periods.

The user would be better to make sure that they were equipped with zic,
and the tzdata source files (or whatever equivalent applies to the system
in use) and update things themselves.

If that's impossible, or just impractical, then it would be better to
simply allow the localtime conversion to be inaccurate for a while (all
system timestamps, in UTC, will still be correct) until things can be
fixed the normal way - just as probably the microwave oven (and other
dumb clocks) usually shows the wrong time for who knows how many days
after one of the time shifts, until it annoys someone enough to correct it.

In this case, the user can even, justifiably, blame the government for
not giving sufficient notice.

So, please, never tell someone:
  | You can work around the problem with one of these POSIX TZ strings. 


  | I realize your interpretation of that wording differs. However, my 
  | interpretation is more plausible and better reflects existing practice.

Some existing practice.   Not all.   In any case

	https://austingroupbugs.net/view.php?id=1639

now exists, and we will eventually get a resolution, one way or
the other.

  | All these behaviors conform to POSIX because POSIX doesn't specify the 
  | behavior when dst has fewer than 3 characters.

But if that's correct, and it might turn out to be, why not simply do
the reasonable thing that tzcode does, and just allow 1 character.
Surely that's better than none, or one with trailing spaces?

  | Glibc treats this same 
  | example as specifying a 512-byte abbreviation for a time zone 4 hours 
  | west of Greenwich.

That's a very odd choice.   Why would they choose to ignore the max length
limit (which is easily capable of making slightly sloppy programs overflow
buffer sizes) but then enforce the minimum length, which (since with my
interpretation, that is still not 0) which is not very likely to have any
noticeable effects at all.    Weird.   Certainly glad I'm not a glibc user.

kre