3 ms·

I must add that I do appreciate you challenging the status quo. Excited to see where your library leads. > modern datetime libraries … in other languages choos

I must add that I do appreciate you challenging the status quo. Excited to see where your library leads. > modern datetime libraries … in other languages choose to not represent these 'missing' local times. Another edge case with throwing errors over gap times is eventually a region’s dst policies may change. So what used to be valid can now be invalid (and vice versa). Updating the library must be done with an audit of existing data, or suffer loud unexpected failures. Thanks for taking the time to address this critic. Easier to be a critic than a creator after all.

ariebovenberg 3y ago
Indeed, structural changes to timezones also need to be handled. Temporal has a good approach here https://tc39.es/proposal-temporal/docs/ambiguity.html#ambiguity-caused-by-permanent-changes-to-a-time-zone-definition https://tc39.es/proposal-temporal/docs/ambiguity.html#ambigu.... Basically: - Store the offset and the tz ID - When deserializing, allow explicit choice what to do: keep the offset (i.e. same moment in time) or keep the local time (i.e. same time on the 'wall clock')