4 ms·

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 a

by zokier 2y ago

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.

fanf2 2y ago
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.
- zokier 2y ago
  That doesn't change the situation of past leap seconds in any way, those still need to be accounted for.
  - fanf2 2y ago
    Do you also need to account for rubber seconds in the pre-1972 version of UTC?
  - spenczar5 2y ago
    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!).
- weinzierl 2y ago
  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.
  - fanf2 2y ago
    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.
kibwen 2y ago
Burntsushi explains here in great detail the reasoning for not supporting leap seconds: https://github.com/BurntSushi/jiff/issues/7 https://github.com/BurntSushi/jiff/issues/7
- zokier 2y ago
  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.
burntsushi 2y ago
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?
- spenczar5 2y ago
  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.
  - burntsushi 2y ago
    Right, but I address this in the issue linked elsewhere in this thread: https://github.com/BurntSushi/jiff/issues/7 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.
    - spenczar5 2y ago
      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.
binarycoffee 2y ago
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 https://github.com/asynchronics/tai-time

by zokier 2y ago

fanf2 2y ago

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.

zokier 2y ago
That doesn't change the situation of past leap seconds in any way, those still need to be accounted for.
- fanf2 2y ago
  Do you also need to account for rubber seconds in the pre-1972 version of UTC?
- spenczar5 2y ago
  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!).
weinzierl 2y ago
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.
- fanf2 2y ago
  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.

kibwen 2y ago

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

zokier 2y ago
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.

burntsushi 2y ago

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?

spenczar5 2y ago
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.
- burntsushi 2y ago
  Right, but I address this in the issue linked elsewhere in this thread: https://github.com/BurntSushi/jiff/issues/7 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.
  - spenczar5 2y ago
    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.

binarycoffee 2y ago

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 https://github.com/asynchronics/tai-time