5 ms·

You speak of time as if it's some directly measurable quantity. Instead, all we have are periodic quantities of various (messy) physical processes or sampling m

You speak of time as if it's some directly measurable quantity. Instead, all we have are periodic quantities of various (messy) physical processes or sampling methods thereof relative to certain underlying models: - _TAI_: Sampled average of ticks in the (very noninertial) frame of the surface an implicitly-defined idealized rigid Earth. Each tick is further a sampled approximation of our definition of a second, which invokes idealizations at absolute zero. - _UT1_: Mostly the same frame as TAI. Each tick is considered a sample, trying to measure the "true rotation" of some idealized rigid Earth, module any geophysics. Note, the definition invokes quite sophisticated models of celestial mechanics, and explicitly ignores certain kinds of "high frequency perturbations". - _UTC_: Based on UT1, but take into account some basic, empirically-measured geophysical processes. Depending on the particular physical processes, models, and sampling methods you choose, the quantity you get for "seconds since 1970" will be different, and there will be (complicated) relationships for how each of those processes transform tick counts between each other. In some cases, the transformations will be a priori impossible, only permitting approximations under simplifying assumptions. IMO, the remarkable thing is that the various ticks all line up as well as they do, which is why we can mostly get away with treating all these as a single unified Ticking Time concept. On the other hand, I also think the various standards do a reasonable job delineating messy reality into potentially useful tick-producing processes and the systems needed to make those practically useful. As a software engineer, the lesson for me is that I can't always ask "what time is it?", "how long has it been?", or "which came first?" Instead, we I may need to shift focus onto different invariants in the problem I'm trying to solve.

afiori 2y ago
> As a software engineer, the lesson for me is that I can't always ask "what time is it?", "how long has it been?", or "which came first?" If we were using TAI instead of UTC we very easily could.
- xelxebar 2y ago
  Really? TAI cannot locate historical dates indefinitely. TAI doesn't even make sense on timescales that exceed Earth's lifetime. It doesn't encode enough information to answer questions about elapsed time of even ideal clocks at real, physical locations to arbitrary precision. Fast enough operations on a distributed database can exceed the precision limits of TAI's definition, making it impossible to canonically order events.
  - afiori 2y ago
    > Fast enough operations on a distributed database can exceed the precision limits of TAI's definition, making it impossible to canonically order events. The TAI would be a sincronization target, just like UTC. Any device can have its own high precision clock and periodically sinchronize with other clocks (just like NTP does) which to my knowledge is how most distributed systems work > TAI doesn't even make sense on timescales that exceed Earth's lifetime I disagree, 10^100 seconds in the future is perfectly valid time in any time system > It doesn't encode enough information to answer questions about elapsed time of even ideal clocks at real, physical locations to arbitrary precision. Those clocks would use the TAI to avoid drifting from each other.
    - Hizonner 2y ago
      > I disagree, 10^100 seconds in the future is perfectly valid time in any time system Professor Einstein would like a word...
krisoft 2y ago
> You speak of time as if it's some directly measurable quantity. They do not. > Depending on the particular physical processes They have chosen their particular physical process: "as if someone stood with a stopwatch"
- xelxebar 2y ago
  > They have chosen their particular physical process: "as if someone stood with a stopwatch" It's not well-enough defined for all purposes. Where is that person standing? Earth's surface is shifting and moving all over the place willy-nilly, so how do you define that particular location in the first place? Over what timescales is that definition valid? What physical process do you mean by stopwatch? What particular synchronization protocols do you define? What physical models do your definitions invoke? Answers to these kind of questions will generally generate mutually-disagreeing time standards. I mean, with suitable transformation rules, they'll often agree up to some precision limit, but if you need anything beyond that, you've now gotta choose the one(s) that best correlate with the natural ticks in your problem domain. Also, any standard like "someone standing with a stopwatch" is forced to just a fiat declare the stopwatch as the Definition of Time, a la the platinum sphere kilogram. We all know how great that was. Do you now want a team of canonical stopwatches and some aggregation process? How do you deal with measurable drift between the tick rates?

afiori 2y ago

> As a software engineer, the lesson for me is that I can't always ask "what time is it?", "how long has it been?", or "which came first?" If we were using TAI instead of UTC we very easily could.

xelxebar 2y ago
Really? TAI cannot locate historical dates indefinitely. TAI doesn't even make sense on timescales that exceed Earth's lifetime. It doesn't encode enough information to answer questions about elapsed time of even ideal clocks at real, physical locations to arbitrary precision. Fast enough operations on a distributed database can exceed the precision limits of TAI's definition, making it impossible to canonically order events.
- afiori 2y ago
  > Fast enough operations on a distributed database can exceed the precision limits of TAI's definition, making it impossible to canonically order events. The TAI would be a sincronization target, just like UTC. Any device can have its own high precision clock and periodically sinchronize with other clocks (just like NTP does) which to my knowledge is how most distributed systems work > TAI doesn't even make sense on timescales that exceed Earth's lifetime I disagree, 10^100 seconds in the future is perfectly valid time in any time system > It doesn't encode enough information to answer questions about elapsed time of even ideal clocks at real, physical locations to arbitrary precision. Those clocks would use the TAI to avoid drifting from each other.
  - Hizonner 2y ago
    > I disagree, 10^100 seconds in the future is perfectly valid time in any time system Professor Einstein would like a word...

krisoft 2y ago

> You speak of time as if it's some directly measurable quantity. They do not. > Depending on the particular physical processes They have chosen their particular physical process: "as if someone stood with a stopwatch"

xelxebar 2y ago
> They have chosen their particular physical process: "as if someone stood with a stopwatch" It's not well-enough defined for all purposes. Where is that person standing? Earth's surface is shifting and moving all over the place willy-nilly, so how do you define that particular location in the first place? Over what timescales is that definition valid? What physical process do you mean by stopwatch? What particular synchronization protocols do you define? What physical models do your definitions invoke? Answers to these kind of questions will generally generate mutually-disagreeing time standards. I mean, with suitable transformation rules, they'll often agree up to some precision limit, but if you need anything beyond that, you've now gotta choose the one(s) that best correlate with the natural ticks in your problem domain. Also, any standard like "someone standing with a stopwatch" is forced to just a fiat declare the stopwatch as the Definition of Time, a la the platinum sphere kilogram. We all know how great that was. Do you now want a team of canonical stopwatches and some aggregation process? How do you deal with measurable drift between the tick rates?