5 ms·

from whenever import ( # For the "UTC everywhere" case UTCDateTime, # Simple localization sans DST OffsetDateTime, # Ful

from whenever import ( # For the "UTC everywhere" case UTCDateTime, # Simple localization sans DST OffsetDateTime, # Full-featured IANA timezones ZonedDateTime, # The local system timezone LocalDateTime, # Detached from any timezones NaiveDateTime, ) Why so many different types? Doesn't ZonedDateTime cover all of the other use cases?

jcranmer 3y ago
No. First, there's a fundamental difference between naïve datetimes and timezone-aware datetimes. Try to combine them in one representation, and you are guaranteed to end up with a broken datetime library that spawns endless blog posts attacking it. Second, there's a more subtle distinction between a datetime which has a known timezone and one which merely has a known instantaneous offset. A timezone is essentially a naïve date time -> tzoffset, albeit one whose values for future dates tends to be surprisingly unrobust. Among the offset-only date times, UTC is a very common case that deserves its own alias. Finally, separating the local-tz datetime from other tz-aware datetimes can be very useful, for if the user changes their local timezone, then a local-tz datetime usually wants to switch the timezone it is using as well.
- assbuttbuttass 3y ago
  IMO, any program using naive timestamps is probably doing something wrong. Same with fixed offsets (except UTC obviously). For local time zone, how often does the local time zone change, and you want to modify all timestamps in the system? That actually seems like a huge pitfall
  - Hackbraten 3y ago
    > IMO, any program using naive timestamps is probably doing something wrong. Here's an example where you'd legitimately want to process and store a naive (wall clock) time object: https://news.ycombinator.com/item?id=39419845 https://news.ycombinator.com/item?id=39419845

jcranmer 3y ago

No. First, there's a fundamental difference between naïve datetimes and timezone-aware datetimes. Try to combine them in one representation, and you are guaranteed to end up with a broken datetime library that spawns endless blog posts attacking it. Second, there's a more subtle distinction between a datetime which has a known timezone and one which merely has a known instantaneous offset. A timezone is essentially a naïve date time -> tzoffset, albeit one whose values for future dates tends to be surprisingly unrobust. Among the offset-only date times, UTC is a very common case that deserves its own alias. Finally, separating the local-tz datetime from other tz-aware datetimes can be very useful, for if the user changes their local timezone, then a local-tz datetime usually wants to switch the timezone it is using as well.

assbuttbuttass 3y ago
IMO, any program using naive timestamps is probably doing something wrong. Same with fixed offsets (except UTC obviously). For local time zone, how often does the local time zone change, and you want to modify all timestamps in the system? That actually seems like a huge pitfall
- Hackbraten 3y ago
  > IMO, any program using naive timestamps is probably doing something wrong. Here's an example where you'd legitimately want to process and store a naive (wall clock) time object: https://news.ycombinator.com/item?id=39419845 https://news.ycombinator.com/item?id=39419845