[tz] C++20 time library

[Paul Eggert]

On 9/20/21 9:51 AM, Howard Hinnant via tz wrote:
> The C++20 standard has adopted the IANA timezone database (not the code) as the basis for a major part of its API:  http://eel.is/c++draft/time.zone
[Retitling since the C++20 time library is a different topic.]

Here are comments about that draft. Hope they help. Unfortunately I got 
only about halfway thru the draft before running out of time.

* Although the draft distinguishes Zones from Links, such a distinction 
is not available on platforms that use a filesystem's hard links to 
implement Links. For example, on Solaris 10:

$ cd /usr/share/lib/zoneinfo
$ ls -li Asia/Chongqing Asia/Chungking Asia/Harbin Asia/Shanghai PRC
303178 -rw-r--r-- 5 root bin 148 2018-09-24 11:26 Asia/Chongqing
303178 -rw-r--r-- 5 root bin 148 2018-09-24 11:26 Asia/Chungking
303178 -rw-r--r-- 5 root bin 148 2018-09-24 11:26 Asia/Harbin
303178 -rw-r--r-- 5 root bin 148 2018-09-24 11:26 Asia/Shanghai
303178 -rw-r--r-- 5 root bin 148 2018-09-24 11:26 PRC

with no indication that Asia/Shanghai is the Zone and the other names 
Links. If there's a reason that the draft distinguishes Zones from 
Links, I suggest explaining the reason, and saying what implementations 
should do when the distinction between Zones and Links is not available. 
Another possibility is to remove the distinction between Zones and Links.


* Minor wording nit: in the "remote_version" description, change "The 
latest remote database version" to "The current remote database 
version". It's possible that the current remote version is a downgrade 
or sidegrade from the local database version; the API still works in 
this case.


* Exception classes. I see a problem with leap seconds here. These 
classes and their related operations seem to be designed only for local 
timestamps that are ambiguous and/or missing due to UTC offset changes, 
such as switching from standard to daylight-saging time. However, 
timestamps can also be ambiguous and/or missing due to leap seconds, and 
this is true regardless of whether the timestamp is local time or UTC.

For example, if there is a negative leap second at the end of 2023, the 
timestamp 2023-12-31 23:59:59 UTC will be missing, and similarly for 
simultaneous localtime timestamps. Conversely, if there is a positive 
leap second at the end of 2025 and local time is not an integral number 
of minutes away from UTC, some (but not all) implementations have 
ambiguous localtime timestamps; see 
<https://mm.icann.org/pipermail/tz/2021-September/030377.html> for an 
example. Also, perhaps a local timestamp's UTC-offset ambiguity could 
interact with the same timestamp's leap-second ambiguity, though such 
cases should be rare.