Remaining TODOs:

• Parsing of %Z
• Parsing of %L

Haelwenn (lanodan) Monnier referenced this ticket in commit 65449dd.

Haelwenn (lanodan) Monnier referenced this ticket in commit 65449dd.

Update: The %L format specifier for the locality/timezone name was introduced for formatting (but not parsing) in commit 6741ce10.

Solution 1: The user should have to explicitly call an exported function (chrono::init_utc_leapsecs()) to load leapsec data to later use chrono::utc. Any error is handled at call time.

Solution 2: There should be a fallback to some leapsec data. Potentially dangerous.

Solution 3: There should be a fallback to just a constant. Potentially dangerous.

Faking UTC conversions (solutions 2 & 3) kinda defeats the purpose of the UTC timescale existing and would make bugs and debugging hell, not to mention the inconsistency between systems' installed versions of the stdlib and leapsec data. I prefer solution 1.

If no UTC leap seconds data is available from the system, the @init responsibile for filling up the utc_leapsecs array fails silently, causing crashes when using the incomplete utc timescale converters (see #642). How should we handle this case?

The current MSD (Martian Sol Date) is currently approximately 52757 days. Add that to 1970-01-01 and you get 2114-06-12. The year (and month and day) are correct when interpreted via the chronology provided by datetime, which is an Earthly one. The datetime module uses the Unix epoch for dates, and so does the Earthly timescales it uses (UTC, TAI, etc.). The user should understand that by using the datetime module, they are reading Martian time via an Earthly (and Unix epoch centric) lens.

If a user wants a Martian interpretation of Martian time, they need a "martian" library, perhaps one that implements the Darian Calendar, and uses the Martian epoch of the MSD (Mars Sol Date) instead of the Unix epoch. This goes for any other chronology (any calendar here on Earth). The stdlib tutorial should clarify this. This "module" modularity was one of the principles behind the design and decoupling of the time::chrono and datetime modules.

~torresjrjr: FYI this crashes if there is no local leap seconds file:

Abort: /home/sircmpwn/sources/hare/time/chrono/timescale.ha:69:3: slice or array access out of bounds

Feel free to open a second ticket if you see fit.

RFC 8536 "The Time Zone Information Format (TZif)", section 3, paragraph 4, states:

NOTE: All multi-octet integer values MUST be stored in network octet order format (high-order octet first, otherwise known as big-endian), with all bits significant. Signed integer values MUST be represented using two's complement.

https://datatracker.ietf.org/doc/html/rfc8536#section-3

General completion, refinement, and changes for add(), hop(), calculus, strategy, etc.