Date: Fri, 6 Mar 2026 20:39:23 -0800 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <0ae0a22c-cc42-4671-bb3c-fdc4c7ec3237@cs.ucla.edu> | Although we could relax these restrictions in later RFCs, that's not | something we could reasonably expect all downstream TZif readers and | producers to implement by November, so for now the restrictions do | impinge on what we can put into America/Vancouver for this issue. First, almost none of that is POSIX as previously claimed, the section 3.3 restriction almost might be, but that's easy to avoid by simply not putting the string into the zone file, if it would violate that spec. That's unlikely to even be noticed, as for most practical purposes it isn't used (few applications want to translate dates very far into the future, as everything there is speculation anyway, so just throw in an extra hundred years of transitions, using whatever the rule would be, instead). If there is an application that breaks (or objects) based upon the section 4 restriction, it ought to simply be dumped (that is, if there are really many applications that read TZif files, aside from tzcode - most others seem to want to parse the input files, which to me is weird, but helpful here, as those files aren't standardised by anyone). I understand maximum sizes can't easily be violated, but anything insisting upon minimum sizes without a very good reason is just being petty. Again, the only place that POSIX ever mandated >=3 char abbreviations is (almost was now) in the specification of the TZ environment variable, and just possibly in that spec for what to set tzname[] values to, none of which isn't being used by TZDATA (the embedded strings not withstanding, those aren't TZ variable assignments, just strings using a similar syntax - POSIX doesn't apply and never did, you could have made them be anything). | Besides, alphabetic time zone abbreviations are problematic given their | ambiguity and lack of standardization, I agree with the premise, those things are useful only for display to humans who understand the meanings of the strings given for zones for whick they are familiar. For anything else they are useless. But I disagree with the conclusion: | and so I doubt whether it'd be | wise to relax the restrictions and encourage use of shorter | abbreviations like "PT" or (shudder!) "O". Doing more of that would be a good thing - the more it is made clear to everyone just how useless those things are in general, the better. No sane program should ever be parsing them, unless some specification gives them some particular meaning in that spec's particular context, as for example the e-mail standards do for a limited set of them. Trying to keep making them useful or less ambiguous, or whatever, is entirely the wrong direction to be headed. | We have trouble enough as it is with these things. No, we have trouble, we need to make even more of it, until people learn just what they are good for (not much), and what they aren't. Continuing to bow to the idiots, just encourages more idiots to appear. | I quite agree, and POSIX.1-2024 started the ball rolling on getting rid | of that garbage. Alas the job is still incomplete. (This is veering off | into a different subject of course.) It is indeed. kre ps: I eventually checked, for anyone who cares, it is J that is unused, not I, in the 1 letter (military) identifier space. Using "O" for summer time in much of Western Europe would seem just fine to me.