[tz] two distinct limits on time zone abbreviation length in tzcode?

Paul Eggert eggert at cs.ucla.edu
Sun Mar 5 11:55:49 UTC 2023


I just noticed that tzcode has two distinct limits on time zone 
abbreviation length. One is MY_TZNAME_MAX (which is 255 on GNU/Linux and 
I expect smaller on other platforms); the other is TZ_ABBR_MAX_LEN 
(which is always 16). The latter limit was introduced in 2005, here:

https://mm.icann.org/pipermail/tz/2005-May/013037.html

These two distinct limits can lead to confusing behavior. For example, 
on GNU/Linux if you compile and build tzcode date you can see this behavior:

   $ TZ=ABCDEFGHIJKLMNOPQ4 date
   Sun Mar  5 07:21:41 ABCDEFGHIJKLMNOP 2023
   $ 
TZ=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4 
date
   Sun Mar  5 11:22:05 UTC 2023

In the first example, the "Q" is silently dropped (it's one more than 
the 16-byte limit), whereas in the second example, the entire TZ string 
is ignored and UTC is silently substituted.

I'm thinking of changing the code so that there's just one limit, 
presumably the higher one, so that we don't get the confusing behavior 
noted above. Comments welcome.


More information about the tz mailing list