Hacker News Reader

Comment by falserum | Hacker News Reader

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.

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

What does TFA mean here? Trifluoroacetic Acid?

The Fucking/Fine/... Article

For educationary purposes: TFA=The Fucking Article

(I’m voting for not being afraid of curse words; if they are relevant)

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 any reason to deviate.

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 (iCal), and most modern libraries (Chrono, Temporal, NodaTime).

You need to account for leap seconds literally any time you are mixing durations/timedeltas with instants/datetimes, otherwise you will get wrong answer. Also needed whenever you parse ISO8601/RFC3339 style strings. For example this (correct) timestamp fails to parse:

    >>> UTCDateTime.from_rfc3339('1998-12-31T23:59:60Z')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/tmp/tmp.4kBsq6IYyF/venv/lib/python3.11/site-packages/whenever/__init__.py", line 797, in from_rfc3339
        return cls._from_py_unchecked(_parse_utc_rfc3339(s))
                                      ^^^^^^^^^^^^^^^^^^^^^
      File "/tmp/tmp.4kBsq6IYyF/venv/lib/python3.11/site-packages/whenever/__init__.py", line 2420, in _parse_utc_rfc3339
        return _fromisoformat(s.upper())
               ^^^^^^^^^^^^^^^^^^^^^^^^^
    ValueError: second must be in 0..59

I do point out that if your internal representation would be simple naive epoch+duration(/timedelta) then you don't need any special accounting for leap seconds when doing time arithmetic like this. The problem arises only if you are trying to be somehow clever with your internal representation (and failing).

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), but not to account for them historically.

I really like Go's "time" package. The only pitfall I can think of is that it doesn't really handle overflow at all.

https://pkg.go.dev/time

And date time parsing sucks with its predefined mask elements.

Go's time package seems like one of the bad ones, since it makes the classic mistake of combining zoned and naive times into the same type (arguably it doesn't support naive times at all).

Reply on news.ycombinator.com