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