[tz] Non-ASCII outside comments?

Guy Harris guy at alum.mit.edu
Wed Jun 25 19:18:31 UTC 2014

On Jun 25, 2014, at 8:47 AM, <Paul_Koning at dell.com> wrote:

> Zone names need to be ASCII, nothing more.  Isn’t this specified by POSIX?

What the latest version of the Single UNIX Specification says of the TZ envrionment variable in 8.3 "Other Environment Variables" is

	This variable shall represent timezone information. The contents of the environment variable named TZ shall be used by the ctime(),ctime_r(), localtime(), localtime_r() strftime(), mktime(), functions, and by various utilities, to override the default timezone. The value of TZ has one of the two forms (spaces inserted for clarity):



		std offset dst offset, rule

	If TZ is of the first format (that is, if the first character is a <colon>), the characters following the <colon> are handled in an implementation-defined manner.

so it doesn't explicitly say that tz database zone names must be ASCII there.  However, it says in 8.1 "Environment Variable Definition" that:

	For values to be portable across systems conforming to POSIX.1-2008, the value shall be composed of characters from the portable character set (except NUL and as indicated below).

so, in theory, a value could have other characters, but such a setting isn't guaranteed to work on all systems.

> In any case, zone names turn into path names, and while some operating systems support Unicode file names, a lot do not.

...and some of the ones that do support them actually support arbitrary sequences of bytes, except for NUL (string terminator) and the pathname separator, as file names, with the interpretation of non-ASCII sequences being based on the setting of an environment variable, so that é might be a single byte of 0xE9 (ISO 8859-1) or two bytes of 0xC3 0xA9 (UTF-8) or....

So, whilst non-ASCII characters might happen to work in some cases, there are probably other situations where they don't work as one might want them to work.

More information about the tz mailing list