On 2024-02-10 02:47, Simon Josefsson wrote:
I think support for those unexpected events belong in your more properly designed str_to_time API family, rather than in a smallest safe replacement for the existing US/English/Gregorian/ISO8601-centric poorly designed ctime API, that for simplicity should continue to be US/English/Gregorian/ISO8601-centric.
Exactly. Even if the US adopted the French Revolutionary calendar, safer_ctime (by whatever name) would not change because that would break its callers, which expect the traditional ctime format.
I doubt very much whether ISO C ctime would change either.
