4 ms·
> Datetimes are a headache to deal with in Python, especially when dealing with timezones, especially when dealing with different machines with different locale
by dom0 10y ago
> Datetimes are a headache to deal with in Python, especially when dealing with timezones, especially when dealing with different machines with different locales.
Anything with date/time calculations is always a pain, probably doesn't really have much to do with the library/language itself, but that the abstraction level that's used (and typically used in other libraries) means that the complexities of calendar and time systems are sprinkled all over application code.
I do have to notice here that always using UTC is not always the right thing to do. For example, evaluating rrules in UTC is rather error-prone (DST).
- mjevans 10y agoIf you're mixing UTC and DST you are doing something wrong.
- deathanatos 10y agoI think what dom0 means is a situation like the following. Say you want to schedule, on a calendar, an event that happens daily at 2PM in your local timezone, say America/New_York. If you record that even as happening at 2200 UTC each day, when DST rolls around, it'll shift to 1PM or 3PM in the local timezone. This is not what the user wants. Here, despite storing everything in UTC and attempting to apply DST as late as possible as if it were a "display issue" — normally the right thing — here results in the wrong outcome.
- mjevans 10y agoIn your example what I said is still true. The user didn't want a precise coordinated time (DST is not a factor for storage/recall); the user wanted a fuzzy reference to local time (DST is a factor for evaluation).