2 ms·

Right, you still might need computers having to deal with the fact those two don't align, which would be messy in a way that is acceptable for (pre)historical d

Right, you still might need computers having to deal with the fact those two don't align, which would be messy in a way that is acceptable for (pre)historical dating, but not for realtime systems. Right, leap seconds it is then, but note that that and minutes/hours/days/years here is something that is only required for human interfaces, while the computer itself only cares about a monotonically increasing seconds counter on its internal clock, which is required to be stopped/started/re-adjusted once in a while anyway. Oh, and conversion between scientific and civil time is then the job of local polities, which they do for timezones anyway.

layer8 4y ago
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.
- BlueTemplar 4y ago
  That relation is established by knowing which standard each clock uses, so I am not really sure what the problem is ?
  - layer8 4y ago
    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.
    - BlueTemplar 4y ago
      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.

layer8 4y ago

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.

BlueTemplar 4y ago
That relation is established by knowing which standard each clock uses, so I am not really sure what the problem is ?
- layer8 4y ago
  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.
  - BlueTemplar 4y ago
    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.