Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Whenever: Typed and DST-safe datetimes for Python

github.com

Post reply on HN
Print view View original

91–100 of 151 posts

Re: Whenever: Typed and DST-safe datetimes for Python

#91

Post by ariebovenberg »

qwertox wrote: post #88
ariebovenberg wrote: post #75

Earlier quoted context omitted.

Author here. It's answered briefly in the FAQ > In casual benchmarks, the pure-Python version is about 10x slower than the Rust version, making it 5x slower than the standard library but still (in general) faster than Pendulum and Arrow. "(in general)" here since the speed compares differently per operation, while the Rust version is faster across the board. That said, there's no operation that is _significantly_ (or…

Thank you. My apologies for not reading the FAQ. Also thank you for sharing your library.

No problem. After all, the readme does go from mentioning Pure Python directly to showing a benchmark graph where it's curiously absent

Re: Whenever: Typed and DST-safe datetimes for Python

#92

Post by ariebovenberg »

iknownothow wrote: post #86

I've read the link and the GitHub readme page. I'm sure I'm in the top 1% of software devs for the most number of timestamps parsed. [1] DST is not a problem in Python. It's parsing string timestamps. All libraries are bad, including this one, except Pandas. Pandas does great at DST too btw. And I'm not shilling for Pandas either. I'm a Polars user who helicopters Pandas in whenever there's a timestamp that needs to…

Author here. It's indeed a hard problem to parse "All ISO 8601 formats and all its weird mutant children that differ by a tiny bit." Since the ISO standard is so expansive, every library needs to decide for itself what to support. The ISO standard allows all sorts of weird things, like 2-digit years, fractional months, disallowing -00:00 offset, ordinal days, etc.

Javascript's big datetime redesign (Temporal) has an interesting overview of the decisions they made [1]. Whenever is currently undergoing an expansion of ISO support as well, if you'd like to chime in [2].

[1] https://tc39.es/proposal-temporal/#sec-temporal-iso8601gramm... [2] https://github.com/ariebovenberg/whenever/issues/204#issueco...

Re: Whenever: Typed and DST-safe datetimes for Python

#93

Post by layer8 »

brookst wrote: post #58
layer8 wrote: post #44

Earlier quoted context omitted.

I would wish for that as well, but it’s unlikely to happen. In the EU for example, some countries would be on the losing side, either by getting “bad” hours or by having to move to a different time zone than their neighbor, which has significant economic consequences. Such countries won’t agree to a DST abolishment that disadvantages them. And for program code, it wouldn’t really help as long as it’s still expected t…

I don’t understand how eliminating DST would impact economics of neighboring countries… today they both change clocks, tomorrow they don’t. What changes?

It’s not eliminating DST as such, it’s switching to a different time zone than their neighbor. Eliminating DST means that either the East-most or West-most country would get unfavorable hours, either in summer or winter. They can mitigate that by changing their time zone, but now that means they’ll be in a different time zone than their neighbor, which they previously shared a time zone with. For example Spain could switch to a different time zone than France, to get less extreme hours of days compared to what is currently Central European Time, but having a time difference would have economic costs between Spain and the rest of CET land. (Arguably, both Spain and France should switch to UTC, based on their proximity to the Greenwich meridian, but a time difference between France and Germany would be even worse.)

I’m not sure how real those costs would be beyond a transitional period, but that’s the discussions that have been going on. It’s a political risk, and nobody wants to be on the losing side of such a change.

Re: Whenever: Typed and DST-safe datetimes for Python

#94

Post by BiteCode_dev »

apeters wrote: post #9

Am I the only one to stick with the std lib, read the docs and changelogs carefully, and implement functions I really need the way my application makes use of them? I learned the hard way, that dependencies kill projects. Not saying this isn't great, thanks for creating it! It does have its use cases, of course.

Functions that you have to document, test and maintain of course. You do that, right? And all the people in your team, they do that and will keep doing that once you leave, right? And they all understand the business domain and all the pitfalls that come with it and have the skill, time, and resources to take care of it, right?

And this for every single problem: time, text, maths, network, parsing, formatting, validating, authenticating...

Re: Whenever: Typed and DST-safe datetimes for Python

#95

Post by BiteCode_dev »

Kwpolska wrote: post #8

> available in Rust or pure Python. Hard pass. The complexity of having to use binary packages or build things is not worth the performance benefit. The pure-Python version requires building from source and passing special flags, so it is not possible to specify it in requirements.txt.

Ah, so you are not using pyQT, numpy, any database driver, pillow or anything using cryptography, then?

Re: Whenever: Typed and DST-safe datetimes for Python

#96

Post by robertlagrant »

freehorse wrote: post #43
mr_mitm wrote: post #33

Earlier quoted context omitted.

> People can't even be bothered to read docs but will just blindly install a package just because someone was able to package it and upload it to PyPI. That's a straw man argument. No one said "blindly". You can very well carefully consider the pros and cons of adding a dependency and arrive at the conclusion that it makes sense. Many PyPI packages are in the Debian stable repositories, you could use that as an addit…

To be fair, comment^^ actually said choice between "reading docs/changelogs carefully, implementing functions", and "adding an extra dependency" which is what comment^ answers to, which to me actually sounds like that the added dependency comes in place of "reading docs/changelogs carefully". I think it matters a lot how much one can trust a 3rd party library, how much it is used, how much it is maintained etc. Moreo…

> If I use python I call pandas to read csvs

So it's you that isn't just using the built in csv parser in this project I inherited. Come back and repent.

Re: Whenever: Typed and DST-safe datetimes for Python

#97

Post by crazygringo »

vjerancrnjak wrote: post #90
crazygringo wrote: post #68

Earlier quoted context omitted.

In my experience it's for calendar-related stuff. You need to store things permanently with the timezone, especially for recurring events. You don't want your scheduled lunch to move from 12 to 1 because it's DST. And so anything server-related with calendars will be making tons of these conversions constantly. And you can't cache things long-term in UTC because the conversions of future events can change, when count…

But lunch is 12 in time, not in date. You have to decide, with short lived datetime what the desired outcome is for today. So you would not store that in UTC but just in time. But yes, I’m ignoring the standard of calendar formats , maybe they are simpler . I read through the article listing all the weirdness of other datetime libraries and I’d say many were covering cases where you behave that timezoned datetime is…

No, my weekly lunch is at 12 every 7 days across a variety of dates. The number of hours between each lunch changes due to DST.

Re: Whenever: Typed and DST-safe datetimes for Python

#98

Post by schrodinger »

orthoxerox wrote: post #25
Mountain_Skies wrote: post #17

Earlier quoted context omitted.

Almost everyone wants to get rid of the twice annual clock changes but are nearly evenly divided on if DST should be permanent or cease to exist. It's a strange artifact of wanting clock noon to be the midpoint of the workday but also wanting to maximize the hours of daylight after work.

Shouldn't people wanting to maximize the hours of daylight after work work night shifts?

Where do I find a software engineering job that has night shifts?

Re: Whenever: Typed and DST-safe datetimes for Python

#99

Post by fragmede »

schrodinger wrote: post #98
orthoxerox wrote: post #25

Earlier quoted context omitted.

Shouldn't people wanting to maximize the hours of daylight after work work night shifts?

Where do I find a software engineering job that has night shifts?

Remote job for a company in a different time zone

Re: Whenever: Typed and DST-safe datetimes for Python

#100

Post by Kwpolska »

BiteCode_dev wrote: post #95
Kwpolska wrote: post #8

> available in Rust or pure Python. Hard pass. The complexity of having to use binary packages or build things is not worth the performance benefit. The pure-Python version requires building from source and passing special flags, so it is not possible to specify it in requirements.txt.

Ah, so you are not using pyQT, numpy, any database driver, pillow or anything using cryptography, then?

For the libraries you listed, the benefits of using a native library are much larger, since they’re wrapping a well-known library that is known to be secure and fully-featured, or since the performance benefits are actually visible in any significant code snippet. But here, there is no Rust library to wrap, and I doubt the performance of a date-time library would have any effect on the performance of virtually all applications (maybe except for calendar apps).
Post reply on HN