[tz] Non-ASCII outside comments?

Matt Johnson mj1856 at hotmail.com
Thu Jun 26 23:56:39 UTC 2014

Guys, please don't forget that zic is not the only usage of the tzdata.  Countless platforms, languages, libraries, and applications use TZ identifiers.  Putting a non-ASCII character in a time zone name is likely going to break many things.
For example, if I have an app that asks the user for their time zone, I might save that time zone into a SQL database varchar column.  One could argue that nvarchar is better, but surely we don't want to require folks to update their application database schemas just to stay current with the latest time zone updates.   I'm sure there are many other scenarios that would be affected as well.

> From: guy at alum.mit.edu
> Date: Wed, 25 Jun 2014 12:39:02 -0700
> To: eggert at cs.ucla.edu
> CC: tz at iana.org
> Subject: Re: [tz] Non-ASCII outside comments?
> On Jun 25, 2014, at 12:17 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:
> > Arthur David Olson wrote:
> >> Should zic permit non-ASCII characters in zone names? In time zone
> >> abbreviations?
> >> If they are permitted, should zic warn about them?
> > 
> > Currently zic allows non-ASCII characters in both places, no?  Or more precisely, zic allows any byte except for ", newline, and the null byte.  So the question is whether zic should stop allowing nearly-arbitrary byte strings, even byte strings that are not properly encoded characters.
> > 
> > The simplest thing to do is to leave zic alone.  I don't see much harm in that, though perhaps I'm missing something.
> +1
> But perhaps the documentation should indicate that:
> 	the byte strings for zone names will be used, as is, in OS calls to create files, and we don't guarantee what effect that will have (for example, on at least one UNIX(R), with the default file system - regardless of whether it's running case-sensitive or case-insensitive - some amount of processing is done on file names to convert them to UTF-16 on disk);
> 	the byte strings for abbreviations will be copied over to the file, without interpretation;
> and that you use non-ASCII characters at your own risk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20140626/d6f736a5/attachment.htm>

More information about the tz mailing list