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

81–90 of 150 posts

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

#81

Post by amluto »

MereInterest wrote: post #51
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…

> Because the local time is the thing that you have immediate access to, with no additional conversions applied.

Only in the sense that BIOS systems historically programmed non-DST-aware local time into the RTC.

Other than that, you actually have no-conversion-needed access to UTC or something UTC-like. Linux mostly tracks the conversion from the hardware clock (TSC, for example) to UTC. NTP gives UTC, and GPS gives something that is a lot closer to UTC than to local time.

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

#82

Post by heavenlyblue »

rhelz wrote: post #69

Really, there is no good technical solution for this, because in part, it is not even a technical problem. The laws about timezones, etc, very from country to country, from year to year etc. And some parts of the world are claimed by two or more different countries, each one of which has an opinion about what time it should be there. One might say "well lets skip all this political b.s. and do everything in UTC" but…

> Imagine two corporate raiders flying in their private jets, biding on the same block of controlling stock: who bought it first would be different depending upon which frame of reference you were in.

Market maker decides that, not them.

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

#84

Post by lijok »

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…

Unfortunately timezones have the nasty ability to change.

See: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...

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

#85

Post by zokier »

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 purpose date/time library. But this is one good litmus test for datetimes, feel free to try it with your favorites.

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

#86

Post by zokier »

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

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

#87

Post by amluto »

joshribakoff wrote: post #80
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.

> don’t know what you mean by “4 pm local time” It means “whenever it is 4pm wherever you are”. As in, i want my alarm to go off at 4pm everyday regardless of whether i am traveling. Python calls it a “naive” time, it has no timezone or offset. Its just a data structure that says “4pm” rather than “4pm eastern time” An example ive used is when a user had to specify schedules for a digital menu board system. When the…

> As in, i want my alarm to go off at 4pm everyday regardless of whether i am traveling.

I think this may be the exception that proves the rule. Sure, this is a valid, if specialized, semantic use case. But you only barely need a LocalDateTime type for this. If you stick that 4pm into a local database, you want to make sure that everything, including the database, knows you’re storing hours, minutes, and seconds relative to an unspecified “local time”.

So IMO this is more of an UnspecifiedZoneTime than a LocalDateTime. (Also, it has no date portion.) It makes no sense to compare it to a UTC or other date+time.

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

#88

Post by amluto »

jcranmer wrote: post #63
amluto wrote: post #60

Earlier quoted context omitted.

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.

If I'm scheduling a meeting, then yes, I am going to want to schedule the meeting using a specific time zone, which may or may not be my local time zone at that moment. But if I'm scheduling when I want my computer to reboot, I want that to be a fixed in time zone in my local time zone. And if I subsequently change my local time zone, I want it to remain at that time in the new local time zone, not the old one. Yes,…

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.

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

#89

Post by azinman2 »

make3 wrote: post #70
bongodongobob wrote: post #66

Earlier quoted context omitted.

Settle down. Most people aren't running or accessing things globally. Local time is perfectly acceptable for a list of obvious reasons.

... a huge fraction of Python code runs on servers everywhere

And a bunch isn’t.

Time is hard no matter what. Having a variety of types and options is a good thing, as long as everything is explicit and convertible.

The wonder if obj-c/swift do well here with NSDate/Date representing a moment in time separate from any calendar/time zone… although the name is confusing for what it represents.

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

#90

Post by bongodongobob »

make3 wrote: post #70
bongodongobob wrote: post #66

Earlier quoted context omitted.

Settle down. Most people aren't running or accessing things globally. Local time is perfectly acceptable for a list of obvious reasons.

... a huge fraction of Python code runs on servers everywhere

Which is exactly what you use time zones for.
Post reply on HN