12 ms·
What we'd like to have: 1. Use SI seconds 2. Keep in sync with earth rotation 3. Avoid leap seconds Pick any two: - UT1: 2, 3 (not 1) [https://en.wikipedia
by FabHK 5y ago
What we'd like to have:
1. Use SI seconds
2. Keep in sync with earth rotation
3. Avoid leap seconds
Pick any two:
- UT1: 2, 3 (not 1) [https://en.wikipedia.org/wiki/Universal_Time https://en.wikipedia.org/wiki/Universal_Time]
- TAI: 1, 3 (not 2) [https://en.wikipedia.org/wiki/International_Atomic_Time https://en.wikipedia.org/wiki/International_Atomic_Time]
- UTC: 1, 2 (not 3) [https://en.wikipedia.org/wiki/Coordinated_Universal_Time https://en.wikipedia.org/wiki/Coordinated_Universal_Time]
- ahubert 5y agoHence, the giant leap second gyroscopes! :-)
- contravariant 5y agoThis is neither here nor there, but "leap second gyroscopes" has turned up some of the weirdest google search results I've seen. A few examples: > Downward movement of work quality? He drew in step a leap second? Gyroscope and accelerometer. Gunfire this weekend outdoors and enjoy shopping here! > Successful troll was a leap second? Gyroscope and accelerometer. Blissful for you. Both inconsequential from a class. Miracle whip classic macaroni salad? > Had lent thee all a leap second? Gyroscope and accelerometer. Shah is threatening hearing or sound. Been fired from their roost and lay siege to the renovation ... Now it's not unusual for webpages to pad their text in order to trick search engines, but these are downright weird.
- zokier 5y agoAfaik additional problem with UT1 is that it's near impossible to tell UT1 time in real-time, because you need to do astronomical observations. So it's kinda impractical as civil time.
- fanf2 5y agoThe rotation of the earth is predictable enough in the short term that it is forecast a year into the future: see IERS Bulletin A https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html https://www.iers.org/IERS/EN/Publications/Bulletins/bulletin...
- thaumasiotes 5y agoAs far as I remember from earlier discussion, the reason that problems arise is that the posix standard defines a "day" as 86400 seconds, so leap seconds need to be erased from history after they've happened. This doesn't make a lot of sense; on March 1st, we don't start pretending that February 29th never happened.
- zokier 5y agoWell, POSIX time is an additional layer of stupidity, but it certainly not the only source of problems; notably these GPS/GNSS related problems do not have anything to do with POSIX time
- account42 5y agoThere is no problem with GPS time, only with converting from GPS time to POSIX time or some other leap-second affected time.
- phicoh 5y agoThe problem is that posix needs the conversion between 'posix time' (seconds since 1970) and the split out year/month/day/hour/minute/second format to work for the future as well. Given that we don't know when there will be leap seconds in the future, this conversion is imposible if we want to take leap seconds into account. So the solution is to either ignore leap seconds (as posix currently does) or have a regular rate of leap seconds (just like leap years). Unfortunately, the rotation of the earth is are not regular enough for a fix rate. At the scale of a human life, leap seconds are completely irrelevant if you want to know the position of the sun. So it is bizar that our civil time has leap seconds. Looking back, that seems to be a historical mistake.
- thaumasiotes 5y ago> The problem is that posix needs the conversion between 'posix time' (seconds since 1970) and the split out year/month/day/hour/minute/second format to work for the future as well. > Given that we don't know when there will be leap seconds in the future, this conversion is impossible if we want to take leap seconds into account. The conversion is impossible anyway. We don't know what the calendar will look like in the future. That isn't a problem that can be solved by any means.
- qalmakka 5y agoJust stick with TAI and convert times to UTC when displaying them is required. The real crap here is the C and POSIX time_t type and its related functions, which are massively out of date (like the 70% of the C standard library). The ISO C standard committee is way too scared of breaking stuff, and when they add something is often utter garbage (look at the whole _s functions fiasco in C11).
- TazeTSchnitzel 5y agoThey should be scared of breaking stuff! If newer standards break things, those newer standards are unlikely to get wide adoption, which prevents actual progress. In any case, while the POSIX and C standards need to accommodate atomic time, that's not enough. The software on top needs to switch to atomic timestamps too.
- qalmakka 5y agoC++ is being adding basically both the kitchen and the sink for years now and still it hasn't broken anything. If anything, lots of warts have been removed now. This whole reasoning doesn't hold when the ISO C standard adds half-assed, optional rubbish to the C standard only to deprecate it the next release. The ISO C can't create a newer, saner C string library or a more useful time library, but it finds the time to devise and release crap like VLA, threads.h or _s functions. Meanwhile, C++20 has stabilized std::chrono::tai_clock, which works on all major operating systems, and does not break anything.
- nly 5y agoC++ is getting timezone database access in stdlib soon too
- akira2501 5y ago> and still it hasn't broken anything. Well, when you explicitly throw ABI backwards compatibility out the window it's far easier to make that claim.
- TazeTSchnitzel 5y ago
- vitus 5y agoSmear it! You sacrifice 1 on days with leap seconds (by 0.001%), but otherwise have all three. https://developers.google.com/time/smear https://developers.google.com/time/smear
- michaelt 5y agoAh yes, for people who want to support leap seconds, but who can happily ignore a clock error of 0.5 seconds :)
- vitus 5y agoI like to think of it as UTC being off by 1s just before the leap second. :)
- q3k 5y ago... I wouldn't call it an error? It's an offset between smeared UTC and non-smeared UTC, like between any two other time standards. It's internally consistent, and for communicating with external entities that expect unsmeared UTC you convert as needed as much as possible. No different from if you were running TAI and communicating with unsmeared UTC, or communicating with TAI while running unsmeared UTC.
- contravariant 5y agoKind of, but differences in time will forever deviate from the SI second so I don't think that really counts. Also 0.0001% of the distance to a GPS satellite is on the order of 200m. Not impossible to work with, but not great either. Though I have no idea what the exact ramifications would be.
- sebzim4500 5y agoRight but as long as GPS satellites are synchronised with each other it doesn't matter all that much how synchronised they are with anyone on the ground, the position they return will still be correct.
- dooglius 5y agoWho is the "we" who wants to keep "in sync" with the Earth's rotation to such high precision? Obviously having 3:30 pm suddenly become the middle of the night would be bad, but we're talking a delta of 18 seconds spread over almost 50 years... hardly big enough to be called "out of sync" in any noticeable sense. Maybe in a millennium or two we'll lose the cultural context of what "it's 5:00 somewhere" meant, but I'm sure the historians could add a blurb.
- globular-toast 5y agoAgreed, 2 seems way lower priority than the other two. You already put your clock "out of sync" with the Earth's rotation every time you move East or West. Nobody actually cares about this. 1 hour timezones are generally granular enough for our needs.
- smichel17 5y ago+1, seems like leap seconds could be covered via a leap hour every 10k years or so. Implemented as a daylight savings change that gets skipped. Implement it at the level of time zones, which is complexity that we already have to deal with most of the time when we want to interface with humans.
- layer8 5y ago> seems like leap seconds could be covered via a leap hour every 10k years or so. The increase is quadratic. Without leap seconds, the difference will be an hour in 1000 years, but already a full day in 5000 years. https://www.ucolick.org/~sla/leapsecs/dutc.html https://www.ucolick.org/~sla/leapsecs/dutc.html -> Effects of disconnecting time from the sun
- smichel17 5y agoAh, that does complicate things. It's not totally clear to me why they think "Given that the first leap hour would not happen for centuries, it is not clear that any systems (legal or technological) would build in the necessary complexity for handling it." It seems like that infrastructure is already in place— the IANA time zone database, and associated technology. UTC would become disconnected from sun-time, but all the other zones could shift relative to it, and it seems like most things would continue to handle it as expected. But, I also trust that other folks have thought about it in more depth than I have. I'm not seriously trying to solve the problem (If I were, I'd get involved in standards committees or similar), and I'm happy to concede that my solution misses key details :)
- account42 5y agoTAI sounds perfectly reasonable for most systems and should be the default IMO - only when displayed to humans do we really need to care about syncing up with the earth's rotation.
- deleted 5y ago[deleted]
- lifthrasiir 5y agoUTC with only leap hours will satisfy all three, assuming 2 can be slightly weakened.
- zokier 5y agoYou can even avoid leap hours if you are willing to have Greenwich not be at +00:00 timezone
- contravariant 5y agoClearly the most realistic solution is to slow down the rotation of the Earth when necessary.
- richardwhiuk 5y agoI think you mean speed up.
- fanf2 5y agoYou need to be able to do both! Since the start of atomic time the day has generally been about 1ms longer than 24x60x60 seconds; at the time of the last leap second in 2016 it was 1.5ms longer. But since last year it has been slightly less than 24x60x60 seconds! For the last few months it has been around 0.25ms shorter.
- contravariant 5y agoWell either way would work I suppose, but yeah let's speed it up a bit. I propose we move the moon closer.
- denton-scratch 5y agoOne of the things we want is a timescale that allows us to put a timestamp on a contemporary event, with the hope that in 2,000 (or 200,000) years, they will be able to work out exactly how long ago it was we were referring to. GMT failed disastrously at that; there have been about 12 mutually incompatible definitions of GMT over the years. So, UTC should retain leap-seconds; that's what UTC means. A new timescale, without leap-seconds, MUST have a new name. I'm betting the ITU will just change the definition, without changing the name.
- themulticaster 5y agoI think you're looking for TAI. UTC = TAI + Leap Seconds (unless I'm missing some minor detail). You don't know how many seconds lie between arbitrary UTC timestamps in the future, but you do know how many seconds lie between arbitrary TAI timestamps in the future.
- echelon 5y agoExactly. The position of the sun doesn't matter that much. Many locations already do daylight saving and would actually prefer to switch their clocks to "saving time", which moves the sun to a point that isn't highest at noon. (As if it actually mattered to keep the sun fixed.) We can always calculate where the sun and stars were positioned if we care.