Re:An Update on Leap Seconds
by layer8 on Monday January 30, 2023 @02:23PM
(#34585056)
Software also cares about which second is which when comparing times originating from different systems, or from earlier/later instances of the same system. A monotonically increasing local clock isn’t sufficient if you can’t tell the relation between time x from your clock and a time y from another clock. So you need some way to establish that relation. Similar for mapping to civil time. You need to know what actual time the source time is.
[ Parent
| on HN ]
Re:An Update on Leap Seconds
by BlueTemplar on Monday January 30, 2023 @03:11PM
(#34585692)
That relation is established by knowing which standard each clock uses, so I am not really sure what the problem is ?
Well, which standard do you use, and how do you ensure that your internal clock remains synchronized to that standard? For example, when starting your system, how do you determine the correct initial value for your clock, and how do you compensate for clock drift? Just having some monotonically increasing counter starting at some arbitrary value isn’t enough.
The current answer is everyone uses UTC, and they keep synchronized by observing the one universally disseminated time, which is UTC.
Re:An Update on Leap Seconds
by BlueTemplar on Monday January 30, 2023 @06:32PM
(#34588276)
How is this relevant to this specific discussion ?
You use and synchronize to the same time standard as the world-metrologists do (TAI), the whole issue is that that's not the one that is being disseminated as the article and I already pointed out.