[tz] C++20 time library

[Howard Hinnant]

On Sep 21, 2021, at 11:58 AM, Paul Eggert <eggert at cs.ucla.edu> wrote:
> 
> 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.

Thanks for taking the time for this constructive criticism.

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

Agreed that the link part of the database may be zero-sized on some platforms.  The API minimizes the distinction between zones and links by having the lookup of all names search both the zones and the links.  The interested programmer can still ferret out a distinction.  But the casual programmer will see the union of zones and links as just one big set.

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

Good point, thanks.

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

This part of the library is specified to be interoperable with Unix Time (http://eel.is/c++draft/time.clock.system#overview-1).  Thus leap seconds are excluded by design.

There does exist a separate facility, utc_clock (http://eel.is/c++draft/time.clock.utc) that is specified to include leap second information.  However to interoperate with the time zone facility, a conversion from utc_time to sys_time is necessary.  This conversion specifies exactly how the leap second is dealt with in the event that the source time_point points within a leap second.

The utc_clock/utc_time facility is mainly useful if you need the duration between two time_points that potentially includes one or more leap seconds.  It is also useful for communicating with external API’s that include leap seconds in their data structures (e.g. https://github.com/HowardHinnant/date/wiki/Examples-and-Recipes#ccsds).

Howard


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mm.icann.org/pipermail/tz/attachments/20210921/9e3b76d6/signature-0001.asc>