Comment by zokier | Hacker News Reader

Comment by zokier | Hacker News Reader

Parent Full thread

While this does seem to be an improvement in general, I find it extremely disappointing that we now got another, greenfield, library that ignores leap seconds and continues the propagation of UNIXy time. I appreciate that it was at least informed decision, and seems to have been tough call to make. So full respect to burntsushi nevertheless.

That makes it mostly uninteresting to me; nice api is nice to have, but I'd personally appreciate correct results more.

From the wider ecosystem C++ std::chrono seems like the only one that shows some promise on this front. Last I checked the implementations were not there quite yet though, and the API definitely didn't seem all that pleasant. Maybe in couple of years we'll see how it'll work out.

Hifitime 4.0 seems like almost the only option at this point, and it is in early alpha still.

I recall using astropy at one point just for time calculations, but it is quite overkill solution.

The quest for perfect datetime lib (for any language) continues.

Burntsushi explains here in great detail the reasoning for not supporting leap seconds: https://github.com/BurntSushi/jiff/issues/7

Yes, that was what I was referring to with

> I appreciate that it was at least informed decision, and seems to have been tough call to make

but you are right, having that link here helps others.

Can you say why you wouldn't want to use a TAI time zone? Like, generate the TZif data for TAI and then just do `jiff::tz::TimeZone("TAI", tzif_data)`. Then you'll get leap second accurate durations.

Can you also say why you need the precision? Like, what's the use case? What happens if your program computes durations that are off because of leap seconds?

I work in astronomy, on detection of asteroids. Catalogs of historical asteroid detections may be reported in UTC from some observatories for historical reasons.

Finding a trajectory that matches several candidate detections is called “linking” and it is very sensitive to time. Being off by even one second will result in a predicted position which is far off course, and so a candidate asteroid detection will not be linked.

Linking is not quite sensitive enough to demand a relativistic time scale, but definitely sensitive enough to require correct leap seconds.

Right, but I address this in the issue linked elsewhere in this thread: https://github.com/BurntSushi/jiff/issues/7

Like yes, scientific applications are a very valid use case for this. But scientific applications usually want other things not afforded by general purpose datetime libraries, like large time ranges and high precision. What I ask in that issue, and what I don't understand, is why folks who want leap second support aren't happy with using specialized libraries for that task, and instead request that leap second support be added to general purpose datetime libraries.

Yeah, I use the specialized libraries. But in Python, this has been painful: the good astronomy library is Astropy’s Time, but everyone uses datetime. So if I want to use a third library - for my database, or for making plots, or whatever - it will use datetime, and now I have to think really hard about how to do conversions. You can imagine how hard that is to get right!

Since Jiff hopes to be ubiquitous (I think? Seems that way) it would be nice if this sort of thing could be avoided. Time is such a fundamental in many APIs that having one common library is very important.

I think I would rather see this supported by paved path conversions to-and-from the specialized library. It's very hard to be all things to all people because there are irreducible trade-offs. The linked issue does a tortured tour through the trade-offs. I found it very difficult to wire in leap second support in a way that was satisfying. And even if Jiff supported leap seconds, that doesn't mean it would be well suited for scientific applications. Do you need more precision than nanoseconds? Do you need a bigger range than -9999 to 9999? If so, those come at the cost of everyone else by using bigger representations. They _could_ be opt-in crate features, but now we're talking about non-trivial additional maintenance/testing burden.

IDK, maybe there is a way to unify everything in a satisfying way, but they seem way too different to me.

Going through TAI is probably the best way for me, I'll have to play around with Jiff to see how practical that is. I'm glad if there is good support for TAI though!

One random use-case (reminded by other thread on the front-page) is that I occasionally have needed to analyze some logs, and get some stats from the data. For example having logs like "2024-07-24T14:46:53.123456Z Foo id=42 started" and "2024-07-24T14:46:54.654321Z Foo id=42 finished", and wanting to get some histogram on how long "Foo" took.

Sure, ideally you'd have some explicit metrics/tracing system or some other measurements for getting that data, but unfortunately in practice that is not always the case and I have to make do with what I have.

Or even more simple, I just want to sort bunch of events to establish a timeline. UNIX style time handling makes that difficult.

NTP adjustments can also cause problems in these sort of cases, but at least the systems I work with are usually kept in relatively tight sync so the "window of uncertainty" is much less than 1s.

I think Jiff should handle that log use case pretty fine? That seems pretty standard. Just parse into a `jiff::Timestamp` and then you can sort or whatever.

TBH I consider the C++ `std::chrono` as the worse possible design. `tai_clock::now` does not actually take into account leap seconds. Unless it does, who knows ("Implementations may use a more accurate value of TAI time."). Likewise, `tai_clock::from_utc/to_utc` does not correct for leap second. It just translates the UTC epoch to the TAI 1958 epoch.

I found Hifitime to be very opinionated and give a false sense of security due to its automatic computation of leap seconds based on historical tables. Yes, leap seconds are announced some ~6 month in advance, but what if you don't update regularly the library? Or if you can't because it is deployed on an embedded system?

In the end I wrote my own minimalistic TAI timestamp library [1] and made the conscious decision to let the user take the responsibility to deal with leap seconds in UTC conversion.

[1] https://github.com/asynchronics/tai-time

Leap seconds are being abolished. The current rotation speed of the earth is very close to 24h/day and is changing very slowly, so it is not very likely there will be another leap second before they are abolished.

While leap seconds are planned to be abolished, there is no plan to give up the coupling of UTC and the Earth's angle.

Leap seconds are just to be replaced by a yet to be defined adjustment, likely leap minutes.

If you don't like leap seconds and don't care about a small (but increasing) deviation from Earth's angle you can do so today: Just use TAI.

Leap minutes are not, realistically, going to happen. The proposed bound on DUTC is something like 100s, and that bound is not fixed. The reason for keeping a bound is to appease those who don’t want to give up on it, but in practice once leap seconds have been abolished the bound will be extended not enforced.

That doesn't change the situation of past leap seconds in any way, those still need to be accounted for.

The nice thing is that you would have a static table of leap seconds, and would not need to poll a URL to check for new leap second data (as Astropy does, for example, on import!).

Do you also need to account for rubber seconds in the pre-1972 version of UTC?

Reply on news.ycombinator.com