[tz] IANA timezone database - request to add Omaha, Nebraska

[Guy Harris]

On Jul 26, 2022, at 4:45 AM, Florian Weimer <fweimer at redhat.com> wrote:

> * Guy Harris:
> 
>> On Jul 22, 2022, at 12:55 AM, Florian Weimer <fweimer at redhat.com> wrote:
>> 
>>> * Guy Harris via tz:
>>> 
>>>> However, once the city was selected, the "Date & Time" setting appears
>>>> to have forgotten the city I chose; it reports Los Angeles, instead.
>>>> Strike 1.
>>> 
>>> This is because the system necessarily has to use the IANA tz identifier
>>> internally for compatibility purposes (e.g., across container
>>> boundaries, or for other system configuration tools).
>> 
>> That is only true if the system necessarily has to use *ONLY* the IANA
>> tz identifier and *CANNOT* store the selected city name.
> 
> It's necessary to use an identifier from a coordinated namespace for
> interoperability purposes.  Boundaries between operating systems from
> different vendors are eroding, so this isn't just about a single system
> that needs to be compatible with itself.  There is also the matter that
> people rewrite the system time zone facilities and go straight to file
> system paths, or use network services to augment the system time zone
> data.  All this requires interoperable identifiers.  And right now the
> IANA identifiers are the cheapest option, and it's also widely used.

You have not shown here that having the Date & Time setting pane

	allow the user to select closest cities from a list based on more than just the cities used in tzids;

	remember the city so that it shows up the next time the user opens that dialog;

	and choose a tzid based on the chosen city and using that as the new tzid;

will prevent that from working.

> Of course, it's possible to hide these identifiers pretty well if you
> only access 

This is an incomplete statement.  What did you intend to say?

>> I am typing this email on a system that has, for what it's worth,
>> passed the Single UNIX Specification test suite and gotten certified
>> as UNIX 03:
>> 
>> 	https://www.opengroup.org/openbrand/register/brand3663.htm
>> 
>> and *its* time does *NOT* show me as being in Los Angeles.
>> 
>> This is presumably because, although it "uses the IANA tz identifier internally" in this sense:
>> 
>> 	$ echo $TZ
>> 
>> 	$ ls -l /etc/localtime
>> 	lrwxr-xr-x  1 root  wheel  45 Jul 21 19:12 /etc/localtime -> /var/db/timezone/zoneinfo/America/Los_Angeles
>> 
>> (it does *NOT* set TZ, it just symlinks /etc/localtime to the
>> appropriate tzdb file), it does *NOT* restrict itself to doing a
>> readlink() of /etc/localtime to determine what to display as the
>> current time zone setting; it, apparently, remembers what city you set
>> as the "closest city" and displays that.
> 
> How does this system implement a programming interface that enumerates
> the TZ rules? The typical way is to use readlink to get the IANA

> identifier, and then use that to look up the rules in the zic input file
> (because the compiled blobs lack this information).

Well, if it shipped the zic input files, it would do it by using readlink to get the IANA identifier, searching through all the zic input files looking for a Zone entry corresponding to that, and proceeding from there...

...the same way it would be done on any other UN*X system that 1) uses the tzdb, 2) provides the zic input files, and 3) has /etc/localtime.

Note that some UN*X systems might not have /etc/localtime and might, instead, rely on the TZ environment variable being set; the API in question should first check the TZ environment variable and, if it's not set, fall back on doing a readlink on /etc/localtime.

(Note also that "fall back on doing a readlink on /etc/localtime" may need to be platform-dependent if not all such systems store the compiled files under a directory named "zoneinfo"; the code would, of course, also have to know where the platform stores the zic input files.)

The only thing that gets in the way of this on macOS is that it doesn't ship the zic input files; you'd have to get them from https://opensource.apple.com/releases (select the release whose source files you want, and look for the version of the TimeZoneData project containing them.