Python time-zone handling

Posted Mar 4, 2020 21:27 UTC (Wed) by perennialmind (guest, #45817)
In reply to: Python time-zone handling by mathstuf
Parent article: Python time-zone handling

Yes! Both units and position/coordinate are worth making distinct. If you add SI seconds to a tz-aware civil `datetime`, you're asking for extrapolation with an emphasis on the "civil" over the "time". If I make an appointment for noon six months out in a region that decides on a whim to adopt DST, I'll should still have my noon appointment. That's how it will work out if I'm using iCalendar, since it stores ISO8601 with IANA time zone id. If I want my Starliner thruster to fire at a precise offset, hopefully I'm using something like CLOCK_MONOTONIC, CLOCK_TAI, or Barycentric Dynamic Time.

Python time-zone handling

Posted Mar 5, 2020 0:39 UTC (Thu) by excors (subscriber, #95769) [Link]

> If I want my Starliner thruster to fire at a precise offset, hopefully I'm using something like CLOCK_MONOTONIC, CLOCK_TAI, or Barycentric Dynamic Time.

CLOCK_MONOTONIC sounds like a bad idea for precise thrusting, since it "is affected by the incremental adjustments performed by adjtime(3) and NTP" (per the man page), so 1 second on that clock may not be 1 second in real time. CLOCK_MONOTONIC_RAW sounds a bit safer.

(Both of those have an unspecified starting point though, so they probably wouldn't have saved Boeing from their Starliner issue where it missed the desired orbit because a clock was off by 11 hours.)