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

51–60 of 150 posts

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

#51

Post by MereInterest »

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…

Because the local time is the thing that you have immediate access to, with no additional conversions applied. Every conversion requires an external source of information. Converting from local time to time zone requires measuring the system clock drift. Converting from time zone to UTC requires knowing which time zone you are in. Converting from UNIX timestamp to UTC requires measurements of the earth’s rotation to know how many leap seconds to add.

I’d propose going in the opposite direction: All timestamps should indicate which clock they were produced from. There is no such thing as a global clock, only conversions between your local clock and the UTC clock.

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

#52

Post by zodiac »

amluto wrote: post #46
cm2187 wrote: post #44

Earlier quoted context omitted.

Then how do you express that something must happen at a date in the future at 4pm local time? If you use UTC based on today's expectation of daylight savings, they may have changed by the time this date happens.

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.

Something like "schedule a reminder to stop using the computer at 10pm so I can sleep by 11pm"? Since I want to sleep at 11pm local time every day

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

#53

Post by darkwater »

cutler wrote: post #38

Why doesn't someone just port Luxon from Javascript which seems to have solved most of these problems. Why are we still reinventing the wheel in 2024?

How do you solve "give me the epoch for 2:30AM" the night daylight changes?

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

#54

Post by falserum »

amluto wrote: post #46
cm2187 wrote: post #44

Earlier quoted context omitted.

Then how do you express that something must happen at a date in the future at 4pm local time? If you use UTC based on today's expectation of daylight savings, they may have changed by the time this date happens.

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.

1. Contract says that goods must be delivered at 4pm.

2. Government suddenly changes the law and moves the offset of whole country.

3. Contract is still valid, goods have to be delivered still at 4pm, but with new offset (so at different utc time).

(I guess timezoned time would still be better than local time, but UTC would not work here)

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

#55

Post by MereInterest »

amluto wrote: post #46
cm2187 wrote: post #44

Earlier quoted context omitted.

Then how do you express that something must happen at a date in the future at 4pm local time? If you use UTC based on today's expectation of daylight savings, they may have changed by the time this date happens.

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 coffee shop may be located somewhere that follows Daylight Saving Time. If you show up when it is "4:00 PM" in the current UTC offset of the coffee shop, I won't be there.

* The coffee shop may currently be located somewhere that follows Daylight Saving Time, but the legislature stops following Daylight Saving Time between now and our meeting. If you show up when it is "4:00 PM" according to the predicted UTC offset of the coffee shop for the day of the meeting, rather than the actual UTC offset of the coffee shop for the day of the meeting, I won't be there.

Saying "local time" implies all of the above. It means that something is being specified according to the local convention of timekeeping.

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

#56

Post by adrian_b »

CJefferson wrote: post #40
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?

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 their time zone.

Because the time zone must be set anyway, it is always better to use inside programs a time that is either UTC or TAI and convert it only for presentation purpose.

For purposes like storing the time at which future events are scheduled, if they are established in local time, so the future correct conversion is yet unknown, a distinct type must be used and that must be a structure with 3 members, date, time of the day and time zone. It must not be a time expressed in seconds or other time units, as it may be used for UTC or TAI.

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

#57

Post by amluto »

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…

> 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 timezone, the appointment doesn’t magically shift an hour as a result.

And any decent time library can handle this just fine as long as you don’t use “local” time. Just specify the actual timezone!

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

#58

Post by amluto »

falserum wrote: post #54
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.

1. Contract says that goods must be delivered at 4pm. 2. Government suddenly changes the law and moves the offset of whole country. 3. Contract is still valid, goods have to be delivered still at 4pm, but with new offset (so at different utc time). (I guess timezoned time would still be better than local time, but UTC would not work here)

> (I guess timezoned time would still be better than local time, but UTC would not work here)

Exactly.

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

#59

Post by amluto »

zodiac wrote: post #52
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.

Something like "schedule a reminder to stop using the computer at 10pm so I can sleep by 11pm"? Since I want to sleep at 11pm local time every day

This is about the only use case for local time that makes sense to me. But this is a UI issue, and it seems to me that that should be something that comes from a UI library or framework, not from libc and or /etc or environment variables.

(I’m using “UI” broadly. A user session on a UNIXy system could have an associated timezone, although such a design should allow changing the timezone without logging on and off. And this “10pm local” thing is quite different from an ordinary zoned time in that “10pm local in 10 days” does not correspond to an actual known UTC time because the local time zone may change.)

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

#60

Post by amluto »

jcranmer wrote: post #50
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.

Schedule an event to occur at 4pm every day, say in crontab.

Works great until you have an office in a different time zone.

The whole concept of a computer belonging to a timezone works to some extent when that computer has a single human tenant, but it falls apart pretty quickly when the scope broadens.

Post reply on HN