Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python datetime pitfalls, and what libraries are (not) doing about it

dev.arie.bovenberg.net

Post reply on HN
Print view View original

21–30 of 150 posts

Re: Python datetime pitfalls, and what libraries are (not) doing about it

#21

Post by kroolik »

Kwpolska wrote: post #14
smitty1e wrote: post #3

I don't think any of the DST complaints are legitimate. If doing work involved with timestamps, not keeping everything in GMT is questionable. GMT is the UTF-8 of timestamps: the low common-denominator rules. The datetime library is mechanism. DST is policy. Policy is wildly variable and your system library would be unmaintainable if it had to chase policy. Just say no.

DST and local time are relevant in calculations when humans are involved. A user in Japan shouldn't be told it's still Sunday just because it's still Sunday somewhere in western Europe. If I set up a recurring meeting every Monday at 10:00, it shouldn't suddenly shift to 09:00 or 11:00 just because of a DST switchover.

What if the meeting is between people in EU and USA, where DST transitions occur at different moments?

Re: Python datetime pitfalls, and what libraries are (not) doing about it

#22

Post by pepoluan »

frumiousirc wrote: post #19

Best code strategy here is twofold. 1. Maximize the code context where date/time is represented as a simple count of Unix epoch seconds. 2. Never pass calendar/clock representations through API methods. 3. Always pass a timezone to methods that require it. 4. Counting, like time, is hard. The only contexts I see where calendar/clock representation are needed are: - Accept calendar/clock info from the user or external…

The problem with Unix Epoch is that it began in 1970.

There are applications where you need dates before 1970 and that starts to get hairy.

Re: Python datetime pitfalls, and what libraries are (not) doing about it

#23

Post by pepoluan »

praash wrote: post #17
TrackerFF wrote: post #5

ISO 8601 is the only way to go. With that said, it's hard to control what systems others use. I frequently work with datasets that have 4-5 different timestamp formats. One of the most annoying bugs I've worked on, was in a table where almost everything followed a DDMMYYYY format - sans a 2-3 month period where the dates were flipped to MMDDYYYY

ISO 8601, ironically, also defined acceptable a (now deprecated) set of truncated date formats such as YY-MM-DD and YYMMDD.

As long as it is now deprecated then it's no longer ironic.

Re: Python datetime pitfalls, and what libraries are (not) doing about it

#24

Post by rightbyte »

kroolik wrote: post #21
Kwpolska wrote: post #14

Earlier quoted context omitted.

DST and local time are relevant in calculations when humans are involved. A user in Japan shouldn't be told it's still Sunday just because it's still Sunday somewhere in western Europe. If I set up a recurring meeting every Monday at 10:00, it shouldn't suddenly shift to 09:00 or 11:00 just because of a DST switchover.

What if the meeting is between people in EU and USA, where DST transitions occur at different moments?

Hmm ... if a problem is hard enough maybe just don't try to solve it?

Treat the meeting time as a string, rather than a time, since it is ambiguous anyway what the organizer meant, and let the user figure out what the string means.

Re: Python datetime pitfalls, and what libraries are (not) doing about it

#25

Post by Glyptodon »

smitty1e wrote: post #3

I don't think any of the DST complaints are legitimate. If doing work involved with timestamps, not keeping everything in GMT is questionable. GMT is the UTF-8 of timestamps: the low common-denominator rules. The datetime library is mechanism. DST is policy. Policy is wildly variable and your system library would be unmaintainable if it had to chase policy. Just say no.

I tend to prefer:

- Things happen/happened at UTC times

- Things will happen at zoneless time + IANA DB label. Though there are some edges. Obviously it's possible to pre-apply and convert to UTC, which is okay, but whether that makes sense to do in practice varies some. Future UTC time of often worthless for understanding human centric dates and times.

Re: Python datetime pitfalls, and what libraries are (not) doing about it

#26

Post by tremon »

smitty1e wrote: post #3

I don't think any of the DST complaints are legitimate. If doing work involved with timestamps, not keeping everything in GMT is questionable. GMT is the UTF-8 of timestamps: the low common-denominator rules. The datetime library is mechanism. DST is policy. Policy is wildly variable and your system library would be unmaintainable if it had to chase policy. Just say no.

If doing work involved with timestamps

Of course, any argument becomes much easier if you're allowed to just discard half the purpose of the thing you're arguing about. The Python datetime library doesn't just exist to record timestamps. From the actual documentation:

> The datetime module supplies classes for manipulating dates and times.

> [..] the focus of the implementation is on efficient attribute extraction for output formatting and manipulation.

Datetime manipulation is part of the explicit focus of the module. So why would you argue that we shouldn't expect said manipulations to be DST-aware?

Re: Python datetime pitfalls, and what libraries are (not) doing about it

#27

Post by sitkack »

Thorrez wrote: post #8
TrackerFF wrote: post #5

ISO 8601 is the only way to go. With that said, it's hard to control what systems others use. I frequently work with datasets that have 4-5 different timestamp formats. One of the most annoying bugs I've worked on, was in a table where almost everything followed a DDMMYYYY format - sans a 2-3 month period where the dates were flipped to MMDDYYYY

Does ISO 8601 fix any of the problems mentioned in the article? It doesn't really seem relevant to me.

> doesn't really seem relevant to me

Isn't this overly 'you' centric? Wouldn't this require access to your inner monologue? Doesn't seem like a referentially invariant supporting argument, to _me_.

Re: Python datetime pitfalls, and what libraries are (not) doing about it

#28

Post by Glyptodon »

jasode wrote: post #20
graemep wrote: post #6

Earlier quoted context omitted.

GMT does not have DST. It is only slightly different from UTC. That said, you should really use UTC. I think you are confusing it with British Summer Time which is GMT +1

>That said, you should really use UTC. No, that "store UTC everywhere" is often repeated but it's incorrect advice when applied to future human-constructed datetimes such as appointments or social events. Future "human-interpreted wall-clock" datetimes cannot be unambiguously stored as future UTC values with perfect roundtrip fidelity. I've tried to explain the difference in previous comment: https://news.ycombinator…

The number of times very smart people seem to think having to alter a pile of UTC times because their associated region has changed their DST behavior is better than having local zoneless and just changing TZDB always weirds me out.

Re: Python datetime pitfalls, and what libraries are (not) doing about it

#29

Post by magicalhippo »

pepoluan wrote: post #22
frumiousirc wrote: post #19

Best code strategy here is twofold. 1. Maximize the code context where date/time is represented as a simple count of Unix epoch seconds. 2. Never pass calendar/clock representations through API methods. 3. Always pass a timezone to methods that require it. 4. Counting, like time, is hard. The only contexts I see where calendar/clock representation are needed are: - Accept calendar/clock info from the user or external…

The problem with Unix Epoch is that it began in 1970. There are applications where you need dates before 1970 and that starts to get hairy.

Signed integers exist. What is hairy about using them?

Re: Python datetime pitfalls, and what libraries are (not) doing about it

#30

Post by falserum »

sitkack wrote: post #27
Thorrez wrote: post #8

Earlier quoted context omitted.

Does ISO 8601 fix any of the problems mentioned in the article? It doesn't really seem relevant to me.

> doesn't really seem relevant to me Isn't this overly 'you' centric? Wouldn't this require access to your inner monologue? Doesn't seem like a referentially invariant supporting argument, to _me_.

Charitable interpretation of previous comment would be “I think it does not seem relevant to problems specified in the article”.

Iso 8601 is about date formatting, while article is about a bit orthogonal to that. (But I agree/hope that ISO 8601 is the future that is less ambiguous than current state)

Post reply on HN