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

101–110 of 150 posts

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

#101

Post by ariebovenberg »

aimor wrote: post #99

I don't really understand why OffsetDateTime doesn't allow adding time deltas (reason provided is that it might have it's offset change relative to UTC). Is the offset supposed to be relative to UTC or is it supposed to be relative to ANY TimeZone (including those with time changes)? I thought it was relative to UTC, but even the other way I just don't understand why that's a problem. I might be making some assumptio…

Author here. "Offset" is indeed relative to UTC. The problem with allowing adding timedeltas is that you give users the impression they are doing valid arithmetic, while they may not be.

Example: You receive a timestamp of an event in Paris: 2024-03-31 01:00:00+01:00. If you allow addition, you may be tempted to think you can "just add three hours" and get 04:00:00+01:00. However, because Paris has a DST transition, you'd actually want to have 05:00:00+02:00

In the end, the choice is between "users know what they're doing, just let them" and "users need to be prevented from making common mistakes". I choose the latter.

Note that also NodaTime doesn't support arithmetic on their OffsetDateTime, for the same reason.

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

#102

Post by zokier »

DandyDev wrote: post #97
zokier wrote: post #86

Earlier quoted context omitted.

I tested this with the library from TFA, and it fails too :( >>> from whenever import UTCDateTime >>> (UTCDateTime(2024, 1, 1) - UTCDateTime(1974, 1, 1)).total_seconds() % 86400 0.0

What does TFA mean here? Trifluoroacetic Acid?

The Fucking/Fine/... Article

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

#103

Post by MereInterest »

amluto wrote: post #57
MereInterest wrote: post #55

Earlier quoted context omitted.

You and I would like to meet at a coffee shop, on a specific date about six months from now, when the clock on the wall of the coffee shop reads "4:00 PM". * The coffee shop may not be located within UTC+00:00. If you show up at UTC time 16:00+00:00, I won't be there. * The coffee shop may not be located in your current time zone. If you show up when it is "4:00 PM" in your local time zone, I won't be there. * The co…

> Saying "local time" implies all of the above. It means that something is being specified according to the local convention of timekeeping. No, it really doesn’t. Saying “4pm at the coffee shop ” means that, and this is a big distinction. If I’m in a different time zone two days before the meeting, looking at my calendar, I sure hope my calendar understands the difference. If I move my entire home outside the timezo…

> No, it really doesn’t. Saying “4pm at the coffee shop” means that, and this is a big distinction.

Some words and phrases, such as "4 pm local time", require some of their semantic meaning to be inferred from context. This doesn't mean that they are meaningless. It means that the relevant context must be provided in order to interpret the phrase. If you and I have been scheduling the coffee shop meetup, then the phrases "4pm", "4pm local time", and "4pm as measured by the applicable standards in the area of the coffee shop on the day of the meeting" are all equivalent.

> Just specify the actual timezone!

This is the problem that I pointed out. The appropriate context for "4pm local time" is "at the coffee shop". However, most calendar programs will only let you provide context such as "Eastern Standard Time". This is the wrong context altogether, and choosing it assumes that the area will have extended the duration of DST between time of scheduling and time of meeting.

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

#104

Post by aimor »

ariebovenberg wrote: post #101
aimor wrote: post #99

I don't really understand why OffsetDateTime doesn't allow adding time deltas (reason provided is that it might have it's offset change relative to UTC). Is the offset supposed to be relative to UTC or is it supposed to be relative to ANY TimeZone (including those with time changes)? I thought it was relative to UTC, but even the other way I just don't understand why that's a problem. I might be making some assumptio…

Author here. "Offset" is indeed relative to UTC. The problem with allowing adding timedeltas is that you give users the impression they are doing valid arithmetic, while they may not be. Example: You receive a timestamp of an event in Paris: 2024-03-31 01:00:00+01:00. If you allow addition, you may be tempted to think you can "just add three hours" and get 04:00:00+01:00. However, because Paris has a DST transition,…

Thank you for answering, I understand the dilemma now and why you chose to force users to explicitly convert to UTC.

When I see the example my thinking is: Well, if you want a time offset relative to Europe/Paris then define your time zone that way instead. Of course I haven't seen other libraries give that option and maybe for good reasons.

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

#105

Post by jcranmer »

falserum wrote: post #95
amluto wrote: post #88

Earlier quoted context omitted.

I don’t know about you, but I have computers that aren’t in the same time zone I’m it. I probably want them to reboot at night where I am, not where they are. But yes, “reboot a laptop at 2am” is in the general category of alarm clock use cases, where a time (but not a date!) with a separately determined time zone makes sense. The OP mentioned LocalDateTime, which doesn’t make sense for this use case.

Instant in history -> GMT+0/UTC Future shedule for humans to coordinate (contracts, meetings) -> ZonedDateTime Personal alarm that should be kept in sync with the sun (e.g. go to sleep) -> LocalDateTime What’s good example/purpose for OffsetDateTime?

OffsetDateTime would be useful for a lot of historical records. For example, if I'm chronicling a WW2 battle in the Pacific, I need to know what the local times of the events were, but I don't necessarily care about knowing the DST rules.

Additionally, most date/time serialization formats (e.g., RFC 822, ISO 3601) only allow you to specify up to OffsetDateTime and don't provide a full timezone reference like US/Eastern.

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

#106

Post by ariebovenberg »

aimor wrote: post #104
ariebovenberg wrote: post #101

Earlier quoted context omitted.

Author here. "Offset" is indeed relative to UTC. The problem with allowing adding timedeltas is that you give users the impression they are doing valid arithmetic, while they may not be. Example: You receive a timestamp of an event in Paris: 2024-03-31 01:00:00+01:00. If you allow addition, you may be tempted to think you can "just add three hours" and get 04:00:00+01:00. However, because Paris has a DST transition,…

Thank you for answering, I understand the dilemma now and why you chose to force users to explicitly convert to UTC. When I see the example my thinking is: Well, if you want a time offset relative to Europe/Paris then define your time zone that way instead. Of course I haven't seen other libraries give that option and maybe for good reasons.

Yeah—the perfect solution doesn't exist. The problem is that fixed-offset datetimes are very common since RFC3339 and ISO8061 don't support timezone names. The result is that you often end up with fixed-offset datetimes that should instead be linked to a IANA tz ID.

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

#107

Post by magicalhippo »

ariebovenberg wrote: post #101
aimor wrote: post #99

I don't really understand why OffsetDateTime doesn't allow adding time deltas (reason provided is that it might have it's offset change relative to UTC). Is the offset supposed to be relative to UTC or is it supposed to be relative to ANY TimeZone (including those with time changes)? I thought it was relative to UTC, but even the other way I just don't understand why that's a problem. I might be making some assumptio…

Author here. "Offset" is indeed relative to UTC. The problem with allowing adding timedeltas is that you give users the impression they are doing valid arithmetic, while they may not be. Example: You receive a timestamp of an event in Paris: 2024-03-31 01:00:00+01:00. If you allow addition, you may be tempted to think you can "just add three hours" and get 04:00:00+01:00. However, because Paris has a DST transition,…

> If you allow addition, you may be tempted to think you can "just add three hours" and get 04:00:00+01:00. However, because Paris has a DST transition, you'd actually want to have 05:00:00+02:00

Since you know the offset then adding three hours should be unambiguous no? Convert to UTC, add three hours, convert back to target timezone, which would net you the correct 05:00:00+02:00.

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

#108

Post by ariebovenberg »

zokier wrote: post #85
falserum wrote: post #36

Across all languages, what are the best libraries, with least amount if pitfalls? (java.time seems good, anything even better elsewhere?)

java.time doesn't handle leap seconds very well :( jshell> ChronoUnit.SECONDS.between(Instant.parse("1974-01-01T00:00:00Z"), Instant.parse("2024-01-01T00:00:00Z")) % 86400 $22 ==> 0 astropy gets you the correct answer: >>> from astropy.time import Time >>> (Time('2024-01-01T00:00:00Z') - Time('1974-01-01T00:00:00Z')).sec % 86400 24.0 of course astropy is bit specialized and not really something I'd use as general pur…

I wouldn't consider 'not handling leap seconds' as a pitfall. If you need to account for leap seconds, you're probably not going to use a general-purpose datetime library.

Unix time ignores leap seconds, so does RFC 5545 (iCal), and most modern libraries (Chrono, Temporal, NodaTime).

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

#109

Post by pgwhalen »

assbuttbuttass wrote: post #41
falserum wrote: post #36

Across all languages, what are the best libraries, with least amount if pitfalls? (java.time seems good, anything even better elsewhere?)

I really like Go's "time" package. The only pitfall I can think of is that it doesn't really handle overflow at all. https://pkg.go.dev/time

Go's time package seems like one of the bad ones, since it makes the classic mistake of combining zoned and naive times into the same type (arguably it doesn't support naive times at all).

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

#110

Post by teddyh »

falserum wrote: post #32
teddyh wrote: post #11

Earlier quoted context omitted.

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

https://ijmacd.github.io/rfc3339-iso8601/ (Maybe useful, comparison)

Useful, but one thing immediately jumps out as incorrect: RFC 3339 does specify a syntax for periods; it’s defined in Appendix A as ABNF token “duration”.
Post reply on HN