Live data from Hacker News

Viewing profile — ariebovenberg

ariebovenberg

HN member
Joined
Mon, Jan 03, 2022, 8:46 PM UTC
HN karma
26
Public activity
18 items

About ariebovenberg

No profile information was provided.

Recent public activity

  1. comment
    Comment #43674916

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

  2. comment
    Comment #43674887

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

  3. comment
    Comment #43673720

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

  4. comment
    Comment #43673631

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

  5. comment
    Comment #39439842

    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…

  6. comment
    Comment #39439804

    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: - St…

  7. comment
    Comment #39423280

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

  8. comment
    Comment #39423126

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

  9. comment
    Comment #39422759

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

  10. comment
    Comment #39422657

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

  11. comment
    Comment #39422340

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

  12. comment
    Comment #39422243

    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. comment
    Comment #39422021

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

  14. comment
    Comment #38048514

    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. story
    Ask HN: Know any validation libraries that guess whether a timestamp is in ms/s?

    When parsing timestamps, Pydantic (a wildly popular validation library for Python) will infer for you whether it's in seconds or milliseconds. I've never encountered behavior like …

  16. comment
    Comment #29811161

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

  17. comment
    Comment #29796409

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

  18. story