If I am asking for how many seconds since 1970, I'm literally asking for that, as if someone stood with a stopwatch (not a cellphone clock!)
How you want to display that in various timezones i do not care
- _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.
If we were using TAI instead of UTC we very easily could.
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.
Professor Einstein would like a word...
They do not.
> Depending on the particular physical processes
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?
People make mistakes.
Why don't you care about that stopwatch's drift over the past 50 years, the tempreture related variation, the errors induced by motion, air pressure and humidity?
Would you prefer a count that's averaged over many from the same manufacturer, or from many over many manufacturers?
I just don't give a damn whether solar time is a couple minutes off of calendar time.
Seconds should be seconds. Solar time is a human construct, it shouldn't affect computers.
That's a mechanical device with multiple sources of error and a need to be wound regularly.
The questions I asked are about common sources of drift in mechanical watches and wether or not they cared enough to attempt to account for them.
The issues you bring up are only relevant to a particular set of devices that can be used as timepieces that measure the amount of time that elapses between its activation and deactivation-- and are are all stopwatches.
Answering your question more directly though, why would you want it in an OS? The OS primarily exists to mediate shared resources, and to a slightly lesser degree to sensibly wrap shared code everyone is definitely using (e.g., chrome and hacker news don't have to care about my LCD driver).
What exactly do you gain by baking TAI into the OS? You lose in update availability, OS install size, application-specific customizability, runtime performance of TAI function calls, .... You'd want to gain something for those costs.
> Why would I use a library for a timezone?
Most people do? Even libc localization isn't a part of the OS (and is fraught with issues; never use libc localization), and that's the most primitive timezone library most people use. Everything else is baked into their language runtime or a third-party like nodatime. TAI isn't special in that regard.
https://en.wikipedia.org/wiki/Geoid#/media/File:Geoid_undula...
Approximations are pretty easy until you get into the details, dammit.
Works if you don't mind a lab bench full of equipment, but doesn't appear to match the specification of the request.
Still, thanks for your input.
The HP 5061 was introduced in 1964, why do you think a counter that can reference the frequency standard is not possible?
You might want to be more rigorous about reading specifications.
> why do you think a counter that can reference the frequency standard is not possible?
How on earth did you strawman my thinking to reach that bogus conclusion?
You might want to be more rigorous about reading comments and projecting.