TZ environment variable

Paul Eggert eggert at CS.UCLA.EDU
Mon May 9 19:23:24 UTC 2005


"Olson, Arthur David (NIH/NCI)" <olsona at dc37a.nci.nih.gov> writes:

> If the TZ environment variable needs to be checked for mischief-making time
> zone abbreviations, the same check needs to be applied to values derived
> from time zone files

Yes, quite right.  Presumably the same check should be applied to each.

Another issue is, what check would be reasonable?  The simplest check
is to restrict the abbreviation to what POSIX requires, namely, N
bytes (where 3 <= N <= TZNAME_MAX) that contain only ASCII letters,
digits, "-", or "+".  A reasonable value for TZNAME_MAX might be 255,
assuming the implementation doesn't specify it.

One way we can be more generous is to lower the "3" to "2" (or "1") in
the above-mentioned check.  I doubt whether it's reasonable to lower
it to zero.  This would be easy.

If we want to allow other characters in the zone name, it will be a
hassle, but one possibility is to relax the character-set
restrictions, as follows:

  * Every character in the abbreviation must be alphanumeric in the
    current locale (as specified by LC_CTYPE).

  * The following checks are relevent for locales with multibyte encodings:

      - The abbreviation cannot have invalid byte sequences.
      - The abbreviation must end in the initial shift state.

A problem with this more-generous approach is that the locale might
change just before localtime() is called; presumably this would
require revalidating the zone.



More information about the tz mailing list