4 ms·
I've been thinking about datetime APIs and how most of them become extremely tedious when you have to account for daylight saving, countries changing time zones
by dancek 7y ago
I've been thinking about datetime APIs and how most of them become extremely tedious when you have to account for daylight saving, countries changing time zones et cetera. I was actually planning to write my own implementation for $language using unix timestamps as internal representation and requiring a timezone whenever parsing or printing. But then I considered leap seconds.
I don't know if there are libraries that can handle leap seconds or is everyone just counting on NTP sync fixing things whenever a leap second occurs.
- masklinn 7y ago> I was actually planning to write my own implementation for $language using unix timestamps as internal representation and requiring a timezone whenever parsing or printing That does not and can not work when trying to represent future local events, which is the vast majority of them as an event normally happens relative to a specific geodesic location. Astronomical events are more or less the only ones which actually routinely get planned in TAI / TT, and astronomical software is thus the only one for which this model could actually work. And then you wouldn't be using unix timestamps (because it's UTC).
- dancek 7y agoYes. Almost everything is subtly broken, and I realized my attempt would be broken too. Didn't feel like a fun hobby project once I realized that.