Not the core API, but a simple custom timezone can be used to implement TAI. I worked on a POC for it, but you can totally test this with the polyfill right now.
Kind of, but not really? The proposal's Absolute represents time in the POSIX timescale, so it is inherently incapable of representing all of TAI, the same as it is inherently incapable of representing UTC.
I attempted to test your library's behavior in this regard, but I do not think you are correctly implementing the proposal's TimeZone. TimeZone.getDateTimeFor() is supposed to take an Absolute and return, in your case, the time that absolute represents in TAI (that time, in the TimeZone). But this:
var one_before = new Temporal.Absolute(915148799n * 1000000000n);
console.log(one_before.toString());
console.log((new Temporal.TimeZone('UTC')).getDateTimeFor(one_before).toString());
console.log((new TAI()).getDateTimeFor(one_before).toString());
That last timestamp being the output supposedly in TAI; but that POSIX timestamp, 915148799 represents 1999-01-01T00:00:30 in TAI. That is, the second line, 1998-12-31T23:59:59 in UTC == 1999-01-01T00:00:30 TAI.
The other direction (getPossibleAbsolutes) is similarly effected.
I attempted to test your library's behavior in this regard, but I do not think you are correctly implementing the proposal's TimeZone. TimeZone.getDateTimeFor() is supposed to take an Absolute and return, in your case, the time that absolute represents in TAI (that time, in the TimeZone). But this:
emits, That last timestamp being the output supposedly in TAI; but that POSIX timestamp, 915148799 represents 1999-01-01T00:00:30 in TAI. That is, the second line, 1998-12-31T23:59:59 in UTC == 1999-01-01T00:00:30 TAI.The other direction (getPossibleAbsolutes) is similarly effected.