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

31–40 of 150 posts

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

#31

Post by guitarnick »

The author provides this example to illustrate inconsistent handling of non-existent datetimes:

    # This time doesn't exist on this date
    d = datetime(2023, 3, 26, 2, 30, tzinfo=paris)

    # No timestamp exists, so it just makes one up
    t = d.timestamp()
    datetime.fromtimestamp(t) == d  # False
Criticisms:

1) The example would fail just as well for any datetime with given tzinfo. Because fromtimestamp returns native datetimes.

2) The timestamp isn't just "made up". Its behaviour is clearly documented in PEP 495, as linked by the author [0]. In this case it consistently corresponds to datetime(2023, 3, 26, 3, 30, tzinfo=paris).

[0] https://peps.python.org/pep-0495/

Finally if we disallow creating non-existent datetimes in the proposed library, how do we represent the 2am in "clock changes forwards at 2am"? Use 3am? There are tradeoffs.

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

#32

Post by falserum »

teddyh wrote: post #11
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

I actually prefer RFC 3339 over an not-freely-available ISO standard.

https://ijmacd.github.io/rfc3339-iso8601/

(Maybe useful, comparison)

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

#33

Post by zokier »

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…

> 1. Maximize the code context where date/time is represented as a simple count of Unix epoch seconds.

Either your values will be different from UNIX timestamp (and you need to write your own conversion functions), or they are not simple count of seconds and will have ambiguities. Neither is not great situation.

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

#34

Post by amluto »

> # The local system timezone > LocalDateTime,

Here’s my feedback: one should essentially never use “local” time. I would even argue that the existence of systemwide local time is a historical mistake.

Why would you ever want to use the “local” timezone of the system on which you are running? If the user is literally sitting in front of a monitor plugged in to the machine, it might be appropriate (but it should be a per-user setting). But if the user is using X forwarding or ssh or a remote desktop, you have no idea what timezone the user is in. (And this was common in the mainframe era!) If you’re servicing a request over the network, you don’t want local time.

The only sort of legitimate use for “local” time I can think of is compatibility with libc and it’s horrible time API.

You can’t even tell what local time means without getenv, which is a footgun.

So maybe LocalDateTime should be called LibcCompatLocalDateTime.

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

#35

Post by airstrike »

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?

Tell those people not to meet at 2am on the night DST changes

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

#37

Post by jncfhnb »

amluto wrote: post #34

> # The local system timezone > LocalDateTime, Here’s my feedback: one should essentially never use “local” time. I would even argue that the existence of systemwide local time is a historical mistake. Why would you ever want to use the “local” timezone of the system on which you are running? If the user is literally sitting in front of a monitor plugged in to the machine, it might be appropriate (but it should be a…

Imagine having the audacity to run software on the machine in front of you

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

#39

Post by Kwpolska »

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?

Calendars like Outlook let you specify a timezone for the event. If it's set to Europe/Warsaw, the US goes out of sync for a few weeks. If America/New_York, the EU does. This still isn't a problem for a meeting between LA and NY, for example (unless the meeting is in the middle of the night).

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

#40

Post by CJefferson »

amluto wrote: post #34

> # The local system timezone > LocalDateTime, Here’s my feedback: one should essentially never use “local” time. I would even argue that the existence of systemwide local time is a historical mistake. Why would you ever want to use the “local” timezone of the system on which you are running? If the user is literally sitting in front of a monitor plugged in to the machine, it might be appropriate (but it should be a…

What is your alternative? I suspect 99.999% of computer and phone users want the time of their local device. Do you want them all to have to explicitly set their time zone?
Post reply on HN