Comment by neutrinobro
4 days ago
Yay! No more leap seconds to manage! This is going to make my life much easier.
Edit...scratch that, now I have to keep track of UT1-UTC as a separately continuously varying parameter provided by IERS instead of tzdata
It shifts the problem elsewhere, though as you suggest it's sometimes still the same people having to deal with it! For example, anyone relying on celestial navigation who had until now been satisfied with up to 1 second of time error is going to need to start keeping track of UT1-UTC before it starts exceeding those old bounds. This will be possibly within a few years, whenever the next leap second would have been inserted/removed.
A chronometer off by one second gives an approximate error of 0.25 nautical miles at the equator. Meanwhile the general precision of celestial navigation is 1-5 nautical miles. If you need high level accurate positioning, celestial navigation is already not an option.
In the open seas, celestial navigation is more than accurate enough. Once you are closer to shore, where the greater precision is needed, better options exists. Lights, ranges, radar, visual, etc.
What do you work on that requires you to care about UT1? Something astronomy-related?
Didn’t Julia choose UT1 for their standard date time library? Although they might want to reconsider with this decision
Julia is not actually doing anything unusual here. When their documentation talks about UT1, this is just a fancy/confusing way of saying that their datetime library isn't aware of leap seconds, just like every other mainstream programming language AFAIK. The abolition of future leap seconds will only reduce the number of weird edge cases this generates, which is all to the good. I suppose they'll need to change the docs, though.
4 replies →
Somewhat the inverse, geodesy.