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

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

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.

(This doesn't break POSIX compatibility, obviously, as POSIX does not discuss the "Date & Time" pane of System Preferences anywhere, for obvious reasons.)

(The reason why it doesn't set TZ is, presumably, because if, instead of selecting a time zone in the Date & Time pane, you just select "Set time zone automatically using current location", it will, if it detects that you've moved across tzdb region boundaries, update the symlink to point to the tzdb file for the new region, and deliver a notification event:

	$ man notify
	notify(3)                BSD Library Functions Manual                notify(3)

	NAME
	     notify_post, notify_register_check, notify_register_dispatch,
	     notify_register_signal, notify_register_mach_port,
	     notify_register_file_descriptor, notify_check, notify_get_state,
	     notify_set_state, notify_suspend, notify_resume, notify_cancel,
	     notify_is_valid_token -- event distribution functions

to all processes, which will cause the new time zone to be used for subsequent calls.  No, that's not a function from BSD, it's a function from Darwin - it uses that heading for all section 3 man pages.

And, yes, this means that the following program:

	#include <stdio.h>
	#include <time.h>
	#include <unistd.h>

	int
	main(void)
	{
		time_t now;

		for (;;) {
			now = time(NULL);
			printf("%s", ctime(&now));
			sleep(5);
		}
		return 0;
	}

will print this:

	Fri Jul 22 02:25:09 2022
	Fri Jul 22 02:25:14 2022
	Fri Jul 22 05:25:19 2022
	Fri Jul 22 05:25:24 2022
	Fri Jul 22 02:25:29 2022

if I switch from my current city to New York, and then back again, in the time zone picker.

> It's just a myth that the IANA tz identifiers are internal data
> invisible to users.

It's definitely a myth that IANA tz identifiers are visible to all users.  Most Mac owner probably haven't even heard of the IANA tz database, have no idea what the current tzid is for their system, and wouldn't have a clue what "America/Los_Angeles" means.

That is a Very Good Thing; cases where end users, other than people who work with code that cares about multiple time zones, have to know or care about tzids should be fixed whenever possible.

> Real systems do not work this way.

Tzids are obviously not invisible to *all* users - anybody who pops open a terminal emulator and types "ls -l /etc/localtime" will see that the file in question is a symlink to a file whose pathname is /var/db/timezone/zoneinfo/ followed by a tzid - but, as noted, the real system running on my machine, and on a lot of other machines, in addition to a related real system that runs on a number of mobile phones with names beginning with "iPhone" - manage not to expose tzids to most of their users.

> Changing that will break interoperability.

Changing *what* will break interoperability?

Not supporting setting the TZ environment variable to a tzid would break interoperability, but that's not what Apple did.

Having the time zone picker in the Date & Time pane of System Preferences display, and remember, the closest city name selected by the user does not break interoperatibility.