Have an api to get the international atomic time (TAI)?

[bjorn3]

I assume that the wall clock api returns UTC time? TAI is basically UTC without leap seconds and associated problems. Now it has been decided to stop using leap seconds for the forseeable future due to the issues they cause for many computer systems so maybe it isn't as important to support anymore, but IMHO suspending usags of leap seconds is only making the problem worse in the future once the difference with terrestrial time has increases sufficiently as it is no longer being tested. Using TAI should avoid these issues if/when leap seconds are reintroduced. Linux supports it using CLOCK_TAI, on other systems I guess manually adding leap seconds would be necessary for implementing this.

[ouillie]

As per the interface definition, the returned timestamps represent the number of seconds since 1970-01-01T00:00:00Z, also known as POSIX's Seconds Since the Epoch, also known as Unix Time, so ya it repeats a second for leap seconds.

You could convert using logic like this. I would like to see separate tai_now and posix_now functions in the spec in case an implementation uses a TAI time source anyway.

[bjorn3]

That requires knowing the exact set of leap seconds, of which new ones can get added amd it requires explicitly writing code for it. In addition during the leap second, the code there doesn't quite work. I suggested TAI support to expose a contiguous time without the wasi program javing to do any extra effort and staying correct even when new leap seconda are added.

[sunfishcode]

Yes, the wall clock is Unix time, which is closely related to UTC. To the extent that UTC moving to drop leap seconds causes problems in the future, those are not WASI's problems. The entire world depends on UTC staying close to terrestrial time, so if those drift too far apart, UTC will surely adapt, and then WASI can follow whatever UTC does, as everyone else will too.

I think TAI is worth considering, though I do see it as less urgent than wall (UTC) and monotonic clocks, which are needed by eg. POSIX and Rust and others. TAI could combine monotonicity with an external meaning, giving it novel use cases.

[edit: the wall clock is Unix time, which is not identical to UTC, but it is closely related]

[ouillie]

Just to flesh out this thread a bit more:

I imagine Unix time is a bit easier to implement since NIST and most other national labs broadcast time signals in UTC rather than TAI. It's silly since UTC is based on TAI and it's easier to convert TAI to UTC than vice versa, but it's technically easier for most platforms to provide Unix time than TAI due to readily available UTC broadcasts.

This is particularly unfortunate because the BIPM has recently started conflating the purposes of TAI and UTC: https://www.bipm.org/en/cgpm-2022/resolution-4. Having stated UTC is "the only recommended time scale for international reference and the basis of civil time in most countries" they want to increase the maximum allowed drift of UTC to whatever happens in roughly a century. UTC should be the basis for civil time, but should not be the international reference time. That should be TAI. Reducing the frequency of UTC adjustments so that it acts more like TAI is silly when we already have TAI for that purpose. Also, I have a bad feeling this will dig us into a hole when after a century without leap seconds we realize we have to adjust all the clocks that were lulled into complacency by this resolution.

TAI has a clear purpose, is simpler than UTC, and is more useful for high-accuracy computing. UTC is a loosening approximation of UT1, but is more ubiquitous and is easier to convert to civil time. I think we should embrace TAI to engender better timekeeping throughout computing, but Unix time is also clearly necessary given the current state of the industry.

[bjorn3]

Both GPS and NTP broadcast the leap second adjustments required to convert between the UTC and TAI. In fact GPS broadcasts time without leap second adjustments, requiring the receiver to do the adjustment instead.