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

131–140 of 150 posts

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

#131

Post by jraph »

CJefferson wrote: post #116
adrian_b wrote: post #56

Earlier quoted context omitted.

Since the appearance of computer networks, all operating systems require during installation an explicit setting of the time zone. This includes Windows and any operating system that chooses to keep the time as local time, because even those need to be able to convert the local time to other time zones. The users who buy a computer with a preinstalled operating system may not see this, but someone has explicitly set…

Windows 11 does not require setting timezone. I just did it in a VM to check I wasn't confused. Neither do android or iPhones.

Any Android install I did myself in VMs or on a phone asked me for the timezone. (lineage and derivative). Maybe it could guess from the GSM network though.

My dumb phone also does, though in terms of UTC offset + DST offset.

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

#132

Post by Hackbraten »

lijok wrote: post #121
Hackbraten wrote: post #117

Earlier quoted context omitted.

That's why they wrote "state the actual timezone" and not "state the actual UTC offset." Actual timezone would mean "2025-01-01 16:00:00 Europe/Berlin," not just "2025-01-01 16:00:00 +01:00."

Even those change

I agree. The city where the cafe is located might be annexed or usurped by another country, and have another timezone imposed on it.

Handling that kind of change would be beyond impractical though?

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

#133

Post by amluto »

MereInterest wrote: post #103
amluto wrote: post #57

Earlier quoted context omitted.

> 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 phr…

> 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.

This is not what the proposed LocalDateTime would do. This is a “naive” time, and those are only really useful for calendar math or when you want to apply a concrete timezone.

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

#134

Post by lelandbatey »

MereInterest wrote: post #55
amluto wrote: post #46

Earlier quoted context omitted.

You start by figuring out what you’re even trying to do. For example, I read your comment three times, and I don’t know what you mean by “4 pm local time” . I don’t even have what I would consider to be a credible guess.

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…

Nah, you need a location; it's right there in the name "local" which implies time at a place. Saying "local time" alone doesn't always give sufficient detail in your example, because you want the device to be able to change it's location (its timekeeping context) while maintaining awareness of the difference between the device's local time and the local time of the thing you've recorded.

"Local time" is basically never "good enough", actually. At a minimum, a time as you've described should include:

- a location where you're tracking the local time

- the destination local time at that location, from which you can derive most of the timekeeping context (time zone), usually

- the current time of the thing doing the computation, in order to accurately compare device to destination time

You then use those to get a UTC time that you can use to do things like a countdown. Or you can just make assumptions about those things and accept they'll be wrong; that's allowed but it's not usually what users want given we KNOW how to give them what they want.

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

#135

Post by sitkack »

falserum wrote: post #30
sitkack wrote: post #27

Earlier quoted context omitted.

> 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)

> I think it does not seem relevant to problems specified in the article

Is a low effort way to make someone form a rebuttal in response to no argument. It is pseudo intellectual way to sound smart while offering nothing in return. As if that persons opinion has weight because “they don’t see the relevance”, I know lots of people that “don’t see relevance”. Is our responsibility to educate their feigned confusion?

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

#136

Post by lijok »

Hackbraten wrote: post #132
lijok wrote: post #121

Earlier quoted context omitted.

Even those change

I agree. The city where the cafe is located might be annexed or usurped by another country, and have another timezone imposed on it. Handling that kind of change would be beyond impractical though?

Good question. I wonder what impact timezone wise the annexation of Crimea had on hypergiants like FAANG. I can imagine some weirdness when rerunning say historical domain events to hydrate a new service.

Wonder if they have libraries to handle such edgecases

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

#137

Post by zokier »

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.

Bigger problem of 1970 epoch is that the 1970-1972 period was confusing time for UTC; having the epoch at 1972 would be arguably much cleaner

Fun excerpt from Wikipedia:

> As an intermediate step at the end of 1971, there was a final irregular jump of exactly 0.107758 TAI seconds, making the total of all the small time steps and frequency shifts in UTC or TAI during 1958–1971 exactly ten seconds, so that 1 January 1972 00:00:00 UTC was 1 January 1972 00:00:10 TAI exactly, and a whole number of seconds thereafter. At the same time, the tick rate of UTC was changed to exactly match TAI.

I'll leave it as exercise to the reader to think of all the implications of whatever timesteps and tickrate shifts that happened pre-1972.

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

#138

Post by autarch »

smitty1e wrote: post #125
autarch wrote: post #15

Earlier quoted context omitted.

> This is the only sane policy. Timezone conversion must be delayed to the very last moment before displaying time to users. No, this only works for datetimes in the _past_. For future datetimes you often must store the datetime in the user's (IANA) timezone. Otherwise your application could be off. And your app could be off by more than one hour. In 2011 Samoa moved across the international date line. See https://ww…

And how can you predict timezones policy changes in the future?

You can't, but if you store a datetime with an IANA time zone, then when the IANA time zone database is updated because of a DST change, your stored datetime is still correct.

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

#139

Post by smitty1e »

Hackbraten wrote: post #127
smitty1e wrote: post #124

Earlier quoted context omitted.

I didn't say "irrelevant". I questioned keeping that in the library.

If the library isn't supposed to do all the heavy lifting, then who is?

Client code between the specific use-case and the general library is how this is typically done.

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

#140

Post by xboxnolifes »

ariebovenberg wrote: post #96
guitarnick wrote: post #31

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.…

Author of the blog post here— 1) You're absolutely right, I'll fix this mistake in the example. 2) "Made up" was perhaps stirring the pot too much ;), but the fact remains that a timestamp is created when one essentially doesn't exist. That this is meticulously documented in PEP495 doesn't change this fact. Note that PEP495 also explicitly describes some of the other pitfalls. Documenting a 'suprise' is not the same…

> Documenting a 'suprise' is not the same as eliminating it

I'd go as far as saying documenting a surprise is basically having a bug and writing "won't fix".

Post reply on HN