3 ms·
The obvious disconnect is the digital bits inside my hardware clock shouldn't need to care about any of this. Then you can change it as often or as little as y
by akira2501 2y ago
The obvious disconnect is the digital bits inside my hardware clock shouldn't need to care about any of this. Then you can change it as often or as little as you like.
- Dylan16807 2y agoI assume you mean high precision clocks in computers because an actual clock won't care about half a second. You could use TAI-ish timestamps right now, but people are going to get confused and make mistakes if your timestamps are almost UTC but several seconds off. And if UTC stays constant then you need to nudge all the time zones around and that sounds even worse.
- akira2501 2y agoSo, you can build complex algorithms to smear leap seconds into clocks at random intervals, or you can use a published database to adjust TAI time to human time. I think the later is less fraught with problems and doesn't require software changes in order to realize updates. You're going to have to deal with the offset one way or another. I'm simply suggesting a means to keep the offset but not have to worry about how to realize that in terms of complicated hardware hacks.
- Dylan16807 2y ago> So, you can build complex algorithms to smear leap seconds into clocks at random intervals, or you can use a published database to adjust TAI time to human time. That's a choice we have right now, today, and as far as I'm aware nobody chooses TAI for their systems. I think that says a lot. > You're going to have to deal with the offset one way or another. Most things don't really care. Oh the clock's off by 1.7 seconds, let's make an adjustment and check again tomorrow. Leap seconds are below the noise floor.