ariebovenberg

5 ms·

1.
by ariebovenberg 1y ago
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 sup
2.
by ariebovenberg 1y ago
No problem. After all, the readme does go from mentioning Pure Python directly to showing a benchmark graph where it's curiously absent
3.
by ariebovenberg 1y ago
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 A
4.
by ariebovenberg 1y ago
Author here. To summarize the long discussion in the issue: 1. I _love_ pure Python packages. Not everybody should be forced to use Rust. I want installing pure-Python to be as easy as possible 2. Having separate names on PyPi (with or with
5.
by ariebovenberg 3y ago
You are correct that there are improvements to be made. The current internal representation is—for the moment—simply the Python standard library. Probably the approach of Chrono is best: allow leap seconds to be represented (i.e. 23:59:60),
6.
by ariebovenberg 3y ago
Indeed, structural changes to timezones also need to be handled. Temporal has a good approach here https://tc39.es/proposal-temporal/docs/ambiguity.html#ambigu... . Basically: - Store the offset and the tz ID - W
7.
by ariebovenberg 3y ago
Author of the article here— I actually did start out basically porting Chrono to Python, but decided against it for two reasons: 1. While I really liked handling local/UTC conversions with the "LocalResult" enum in Rust, it t
8.
by ariebovenberg 3y ago
Author here— This is a conscious decision, I'll explicitly address this in the FAQ soon. As I commented elsewhere, this is completely in line with industry standards (iCal, Unix time) and other modern libraries. I don't (yet) see
9.
by ariebovenberg 3y ago
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
10.
by ariebovenberg 3y ago
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 shoul
11.
by ariebovenberg 3y ago
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 even
12.
by ariebovenberg 3y ago
Author of the post here— They are emoji. I've added plain text to the table now, so it is readable without them. edit: I've used a workaround to display emoji as images now
13.
by ariebovenberg 3y ago
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
14.
by ariebovenberg 3y ago
Was this inspired by another library or language? Or simply a reaction to the all-too-common experience of dealing with under-specified data?
15.
Ask HN: Know any validation libraries that guess whether a timestamp is in ms/s?
2 points by ariebovenberg 3y ago|3 comments
16.
by ariebovenberg 5y ago
Author here. I in my article I didn't touch on 'log poinsoning'[1], what they could be referring to. Vulnerability to log poisoning really depends on _what_ you do with your logs. If you display them on a webpage, beware of X
17.
by ariebovenberg 5y ago
__slots__ is a good way to make Python classes more efficient. There is a catch though: you need to use it consistently in all base classes, or you don't get the full benefits. This is easy to forget, and there's nothing warning y
18.
Show HN: Detect broken __slots__ in Python libraries(github.com)
2 points by ariebovenberg 5y ago|1 comments