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.