5 ms·
The thing Biff gets right that gnu `date` and most stdlib datetime APIs get wrong: it treats "civil time" and "absolute instants" as different types. You cannot
by jibaoproxy 4mo ago
The thing Biff gets right that gnu `date` and most stdlib datetime APIs get wrong: it treats "civil time" and "absolute instants" as different types. You cannot answer "what's 30 days from 2024-03-08 in America/New_York" without picking a side — DST means that's either 29d23h or 30d0h of elapsed time, and most APIs silently pick one without telling you.
Jiff (the underlying Rust crate) gets this from Temporal in TC39, which is the first time JS standards have led anything datetime-shaped. Hopefully the rest of the ecosystem catches up — Python's `zoneinfo` only landed in 3.9 and `datetime.timezone` still has sharp edges.
- cyberrock 4mo agoThat's an interesting perspective because if I use America/New_York I would assume that it's subject to the laws of New York City. If I wanted a different DST regime I'd just use +4, +5, or a different city.
- burntsushi 4mo agoThat's a complaint against how time zones are themselves named and organized. See https://ftp.iana.org/tz/tzdb-2022b/theory.html https://ftp.iana.org/tz/tzdb-2022b/theory.html for all the gory details. Using +4 or +5 explicitly instead of a time zone when DST is relevant is bad juju. Then your arithmetic can become silently wrong in subtle ways when it cross a DST boundary.
- cyberrock 4mo agoAh I see, I didn't understand the original question properly. "Choose one side of DST or another" was meant for the time literal, not the TZ. That's my bad.