There is a forthcoming proposal for JavaScript date/time handling, Temporal. This proposal is currently at Stage 3. When it reaches Stage 4, I would kind of like it if t-a-i provided some kind of useful integration with Temporal. Here is the documentation for this new API.
This may be an interesting venture because of some possible points of complexity.
Temporal makes the same choice (mistake?) which many date/time handling APIs do, which is to treat Unix time as the fundamental underlying bedrock of time, from which all time zones are derived. In reality, International Atomic Time (TAI) is a deeper bedrock from which Unix time is derived. This is a basic design decision in Temporal and not something which is ever going to change. So, any integration with Temporal will require t-a-i to misrepresent TAI as a "time zone" derived from Unix time, not the other way around.
Temporal.Instant represents a fixed point in Unix time, which, under some models of the relationship between Unix time and TAI, is in fact ambiguous. Temporal does offer some mechanisms for resolving ambiguity but I think they don't work in this case because they assume the reverse relationship where Unix time is unambiguous and the time zone is ambiguous.
Furthermore, Temporal does not acknowledge that certain Unix times never happened. Unlike most "time zones", converting these Unix times to TAI must fail somehow.
Temporal.TimeZone does not appear to account for the possibility of time zones where the rate at which time passes differs from that under Unix time. Under the "smear" model for leap seconds, Unix time and TAI pass at different rates during inserted or removed time. It's entirely possible to carry out conversions, but the offset between one and the other will be continually changing. What problems does this cause?
For timeZone.getNextTransition, for example, there is an implicit assumption that the offset between zoned time and Unix time only changes on certain discrete occasions. During a smear, do we simply return the current instant, because the offset is continually changing? Does this break anything?
One workaround for this problem is to simply abandon support for the smear model and use the "overrun", "break" and "stall" models. But this doesn't help us for pre-1972 history. From 1961 to 1971 inclusive, TAI and Unix seconds were simply different lengths, no matter what model one considers.
Temporal.Instant seems to use nanoseconds, whereas JavaScript Date APIs have used milliseconds up until now. I have some secret scaffolding which allows absolute precision by using arbitrary precision ratios of BigInts internally, so this should be doable, although I am still curious as to what the shape of this "exact" API should be.
There is a forthcoming proposal for JavaScript date/time handling,
Temporal. This proposal is currently at Stage 3. When it reaches Stage 4, I would kind of like it ift-a-iprovided some kind of useful integration withTemporal. Here is the documentation for this new API.This may be an interesting venture because of some possible points of complexity.
Temporalmakes the same choice (mistake?) which many date/time handling APIs do, which is to treat Unix time as the fundamental underlying bedrock of time, from which all time zones are derived. In reality, International Atomic Time (TAI) is a deeper bedrock from which Unix time is derived. This is a basic design decision inTemporaland not something which is ever going to change. So, any integration withTemporalwill requiret-a-ito misrepresent TAI as a "time zone" derived from Unix time, not the other way around.Temporal.Instantrepresents a fixed point in Unix time, which, under some models of the relationship between Unix time and TAI, is in fact ambiguous.Temporaldoes offer some mechanisms for resolving ambiguity but I think they don't work in this case because they assume the reverse relationship where Unix time is unambiguous and the time zone is ambiguous.Temporaldoes not acknowledge that certain Unix times never happened. Unlike most "time zones", converting these Unix times to TAI must fail somehow.Temporal.TimeZonedoes not appear to account for the possibility of time zones where the rate at which time passes differs from that under Unix time. Under the "smear" model for leap seconds, Unix time and TAI pass at different rates during inserted or removed time. It's entirely possible to carry out conversions, but the offset between one and the other will be continually changing. What problems does this cause?timeZone.getNextTransition, for example, there is an implicit assumption that the offset between zoned time and Unix time only changes on certain discrete occasions. During a smear, do we simply return the current instant, because the offset is continually changing? Does this break anything?Temporal.Instantseems to use nanoseconds, whereas JavaScriptDateAPIs have used milliseconds up until now. I have some secret scaffolding which allows absolute precision by using arbitrary precision ratios of BigInts internally, so this should be doable, although I am still curious as to what the shape of this "exact" API should be.