TZ environment variable

[Mark Davis]

I'm a little fuzzy about what you are talking about. If it is the internal
IDs (eg "Asia/Shanghai"), they should never contain anything but a very
constrained, locale-independent set:  A-Z, a-z, space, slash.

If you are talking about localized names, like "Heure avancée de Chine" or
"中国标准时间" or "Шанхай", those can't be limited in any way because we can't
know that the customary form is alphanumeric. But these *don't* belong in
the tz database in any event!

‎Mark

----- Original Message ----- 
From: "Paul Eggert" <eggert at CS.UCLA.EDU>
To: "Olson, Arthur David (NIH/NCI)" <olsona at dc37a.nci.nih.gov>
Cc: "Tz (tz at elsie.nci.nih.gov)" <tz at lecserver.nci.nih.gov>
Sent: Monday, May 09, 2005 12:23
Subject: Re: TZ environment variable


> "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.
>
>
>