Clive, Thank you for responding. I am so sorry to hear that forever my time in the Ubuntu time zone map will be tied to Chicago. That’s very disappointing news. Regards, Bob Wilmes Sent from my iPhone

On Jul 21, 2022, at 11:03 AM, Clive D.W. Feather <clive@davros.org> wrote:

Bob Wilmes via tz said:

...

Can you please tell me how I request that Omaha, Nebraska, USA which is in the Americas Central time zone and uses daylight savings time, can be added to the "Olson" timezone database used by Ubuntu?

Dear Bob,

Has Omaha had the same time as Chicago since 1970? If so, then the zone America/Chicago is the one that serves Omaha. However, if there has been a difference, you should provide evidence of it and post it to this mailing list so that action can be taken.

Currently it appears that all of the US part of the Central zone has been the same since 1970 apart from a few parts of Indiana and North Dakota plus the Wisconsin border area of Michigan.

Hope that helps.

Clive

-- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

On Jul 21, 2022, at 10:06 AM, Bob Wilmes via tz <tz@iana.org> wrote:

I am so sorry to hear that forever my time in the Ubuntu time zone map will be tied to Chicago. That’s very disappointing news.

That's Ubuntu's failure, not ours. Or, should I say, "failures", plural: When installing Ubuntu 22.04 on a new VM (which I'm doing, for the Nth time, due to *other* failures - thanks, GNOME!), the time zone selector in the installer allowed me to select "Omaha" and offered several Omahas from which to choose. (It also allowed me to select the city in which I live, which has less than 1/10th the population of Omaha, Nebraska, although it's much larger than Omaha, Illinois. To be fair, said city *is* a significant city in the San Francisco Bay Area....) 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. Furthermore, it doesn't understand all the cities that the installer's time zone selector does; I couldn't select my city, just Los Angeles, and couldn't select Omaha either. Strike 2. macOS does *not* have these problems. Its time zone selector in System Preferences knows Omaha, as well as the city I'm in, and, if I select the city I'm in, it *remembers* that and displays that as the "closest city" setting. *That's* what Ubuntu should be doing, and, if it did that, you won't see "America/Chicago" unless you look at environment variable settings. And there's nothing particularly special about Omaha; if the time zone database took on the task of supporting names for a significant set of cities, rather than one city per tzdb region, there's a city of around 21 million people that is not in the tzdb - its zone is Asia/Shanghai (the population of which is larger than Beijing). And, yes, there has been at least one complaint to the list that there's no Asia/Beijing; we did not add it.

On Jul 22, 2022, at 12:55 AM, Florian Weimer <fweimer@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.

On 7/26/22 04:45, Florian Weimer via tz wrote:

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

It depends on what "TZ rules" means. If it means the Rule lines in .zi files, that's not intended for end-user consumption. That information is absent from the TZif files output by zic. So I doubt whether you meant that. If it means the TZ strings at the end of TZif files, then that would be determined by enumerating all the TZif files and looking at their contents. But this means one first needs to enumerate all the TZif file names which is begging the question. If it means to enumerate all the supported Zone and Link names, then on a pre-2017c implementation that would mean recursively looking for all TZif files under /usr/share/zoneinfo (or whatever) and discarding names of non-TZif files. Although doable, this is awkward. A simpler way with 2017c-and-later is to read /usr/share/zoneinfo/tzdata.zi and look for Link and Zone lines. If it means to enumerate only Zones and omit Links, which is what I think you mean, then readlink will work only if Links are implemented via symbolic links. Although Debian and Red Hat based systems do that, the default TZDB installation does not (it uses hard links), and Alpine, macOS, NetBSD, OpenBSD, OpenSUSE etc. use the default either because it is the default or because it is a bit more efficient. (FreeBSD uses neither hard nor symbolic links: it uses copies and I don't know why.) And I think Android has its own scheme where all the entries are in a single file. So although readlink is common, I wouldn't call it "typical". A good way to enumerate only Zones with 2017c-and-later is to read the installed tzdata.zi file and look for Zone lines. Unfortunately only some systems (e.g., Debian, Red Hat) install tzdata.zi; however, as a reasonable substitute one can use the third column of zone1970.tab, as this enumerates all but legacy Zones like CST6CDT, Etc/GMT+10, and Factory. Reading tzdata.zi and/or zone1970.tab should be more portable and faster than issuing readlink calls. Distros like FreeBSD should consider installing tzdata.zi as that will make it easier for applications to enumerate all supported Zone and Link names, as well as do other things.

On Tue, 26 Jul 2022 at 15:53, Guy Harris via tz <tz@iana.org> wrote:

...

If it means the Rule lines in .zi files, that's not intended for end-user consumption. That information is absent from the TZif files output by zic. So I doubt whether you meant that.

Given that he said "look up the rules in the zic input file (because the compiled blobs lack this information)", he's presumably aware of that, and probably *did* mean "the Rule lines in .zi files".

If some software needs information based on that - i.e., needs to know when the current tzdb region, or a particular tzdb region, changed or will change its offset from UTC or its abbreviation - then perhaps its developers should propose a new API that implementations such as the tzdb reference implementation could provide. (Hopefully those developers are aware that a given tzdb region can change, over time, which rule sets it uses!)

For exactly this reason, I would argue that attempts to extract raw input rules to, say, display general UI descriptions such as "Daylight Saving Time in effect from the second Sunday in March at 02:00 through the first Sunday in November at 02:00" would generally be misguided. I've seen some interfaces that assist in zone selection by displaying the next upcoming clock change for a given zone, which is already straightforward to get from compiled TZif files. If you want to provide an end-user with a somewhat fuller picture of how a zone might behave seasonally, you could extend this to the next (pair of) forward and backward transitions, if any, which in most cases would be adequate to describe the next year or so. For America/New_York today, this might look something like "Clocks go backward 1 hour on Sunday 6 November 2022 at 02:00 and go forward 1 hour on Sunday 12 March 2023 at 02:00." (Of course, it would be easy to naïvely render those timestamps with their post-transition times of 01:00 and 03:00, respectively, but the conventional pre-transition 02:00 could be determined by intentionally calculating the display times with their pre-transition offsets.) Note that, because DST can be negative, it is more useful/descriptive to describe the direction and amount of actual clock movements than the state of an arbitrary toggle. To handle some common edge cases, consider describing the next transition however far ahead it may be (to allow for a region announcing a change to its time zone or rules several years out), but maybe only look ahead ~12 months from that point for a second one (to avoid implying recurrent seasonality that may not exist). -- Tim Parenti

* Paul Eggert:

On 7/26/22 04:45, Florian Weimer via tz wrote:

...

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

It depends on what "TZ rules" means.

If it means the Rule lines in .zi files, that's not intended for end-user consumption. That information is absent from the TZif files output by zic. So I doubt whether you meant that.

There is TzdbZoneRulesCompiler, which I think is used to compile the data which can be accessed through these interfaces: <https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/time/zone/...> There I think ICU has something in this area, too, and the time zone library that was standardized into C++ has a backend based on .zi files, too (for systems which do not install the TZif files).

Distros like FreeBSD should consider installing tzdata.zi as that will make it easier for applications to enumerate all supported Zone and Link names, as well as do other things.

But that file also lists the (abbreviated) rules, and you wrote above that those aren't for end-user consumption. Thanks, Florian

* Paul Eggert:

Looking back at your original question "How does this system implement a programming interface that enumerates the TZ rules?" <https://mm.icann.org/pipermail/tz/2022-July/031702.html> I think the answer is that TZif files don't do that. That is, they don't give you access to the Rule lines, only to the effect of the Rule lines on transitions and/or TZ strings.

But that means the software has to obtain the IANA time zone name (which is not part of the TZif data, either), and that exposes the allegedly invisible, internal identifier across an interface boundary. Thanks, Florian

On 8/1/22 01:35, Florian Weimer wrote:

* Paul Eggert:

...

Looking back at your original question "How does this system implement a programming interface that enumerates the TZ rules?" <https://mm.icann.org/pipermail/tz/2022-July/031702.html> I think the answer is that TZif files don't do that....

But that means the software has to obtain the IANA time zone name (which is not part of the TZif data, either), and that exposes the allegedly invisible, internal identifier across an interface boundary.

Sure, names like America/Los_Angeles are visible across an operating system's internal interfaces, but those interfaces need not be exposed to the end user. By the way, earlier I thought that you were asking about Rule names like "US" and "Canada" but I see now that you're asking about Zone names like "America/Los_Angeles" and Link names like "US/Pacific". Rule names are internal to TZDB, and I hope downstream users aren't relying on them staying the same from one release to the next, or even within a single release (as the Rule names in tzdata.zi differ from those in 'northamerica'). Another way to put this is that Zone and Link names are covered by the interface stability guidelines[1]; Rule names are not. [1] https://data.iana.org/time-zones/theory.html#stability

On 7/26/22 12:15, Guy Harris via tz wrote:

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.

Thanks for the pointer. I just looked at that URL, which pointed me to: https://github.com/apple-oss-distributions/TimeZoneData which pointed me to: https://github.com/apple-oss-distributions/TimeZoneData/tree/TimeZoneData-99... which has a tzdata2021a.tar.gz: https://github.com/apple-oss-distributions/TimeZoneData/raw/ffacbba48c11246d... Unfortunately I see nothing that says how this tar.gz file is used, which means it's unclear exactly which Zone lines are effective. So it'd be helpful if Apple installed a tzdata.zi file as you recently endorsed. Interestingly enough, Apple's tzdata2021a.tar.gz differs from upstream, which is here: https://ftp.iana.org/tz/releases/tzdata2021a.tar.gz in that Apple's uses rearguard format, and Apple's contains the file yearistype.sh which was removed in 2020b (and hadn't been used since 2000f). Other than yearistype.sh which should be irrelevant, Apple's tzdata2021a.tar.gz is identical to the tzdata2021a-rearguard.tar.gz generated by 'make rearguard_tarballs'. I guess that Apple names their file 'tzdata2021a.tar.gz' instead of 'tzdata2021a-rearguard.tar.gz' for some backward-compatibility reason (or perhaps they're embarrassed by the word "rearguard" :-).

On Jul 26, 2022, at 2:11 PM, Doug Ewell <doug@ewellic.org> wrote:

Isn’t this simply a matter of maintaining two strings:

Yes, that's exactly what I was saying.

Then when the “select time zone” UI is invoked again, the user’s selected city is set as the list default, and in general when the “zone” needs to be displayed to the user, the city is displayed instead or in addition. But the real tzid is still used by the system for time conversion purposes.

Exactly. No breaking of interoperability is caused by the suggested UI improvement.

On Fri, Jul 22, 2022 at 3:06 AM Robert Elz via tz <tz@iana.org> wrote:

Date: Fri, 22 Jul 2022 09:55:44 +0200 From: Florian Weimer via tz <tz@iana.org> Message-ID: <877d45funz.fsf@oldenburg.str.redhat.com>

| It's just a myth that the IANA tz identifiers are internal data | invisible to users. Real systems do not work this way.

android seems to, I have never seen a TZ string of any kind in normal use of any of my android devices - yet I know it is in there, in some form, somewhere.

(off-topic from ubuntu's ui problems at this point, but...) yeah, Android uses a system property to communicate system-wide timezone changes. in libc, where tzcode checks the environment variable, we check the system property. annoyingly we _also_ check the environment variable, which is useful for command-line stuff (where it's a workaround for the lack of functions in POSIX that take an explicit timezone). this shows up in profiles even; if you profile the logcat command which takes a bunch of timestamps and formats them, it spends a depressing amount of time in getenv(). the system properties stuff is cheap to ask "has it changed?" after your first lookup. theoretically i could make the environment functions try to keep track of changes, but putenv() breaks that. (environ is no great help either.) i guess i could look for putenv() with "TZ=" and have another "all bets are off" flag, but, well, i've never been quite annoyed enough by logcat's performance issues to try to go there.

The real issue is developer laziness / lack of time, combined with the fact that (even on systems that don't attempt to hide that tzdb timesone identifier) users almost never see it, it tends to get used once when the system is installed, then ignored forever after. That tends to make it a low priority for many systems to provide a better solution.

kre