Precisely. If I wanted to express 2009-01-01 00:00:33 TAI with a POSIX timestamp, the result would depend on how the implementation handles leap seconds (discussed at length earlier in this thread). Since POSIX time_t is indeed a count of "non-leap seconds since the Epoch", there really isn't an entirely "correct" way of doing this under that structure.

UTC TAI TAI-UTC POSIX time_t

2008-12-31 23:59:58 2009-01-01 00:00:31 33s 1230767998

2008-12-31 23:59:59 2009-01-01 00:00:32 33s 1230767999

2008-12-31 23:59:60* 2009-01-01 00:00:33 33s (depends)

2009-01-01 00:00:00 2009-01-01 00:00:34 34s 1230768000

2009-01-01 00:00:01 2009-01-01 00:00:35 34s 1230768001

On Fri, Jul 1, 2011 at 12:51, Guy Harris <guy@alum.mit.edu> wrote:

> but sometimes two values on one side map to one value on the other side.

...so that there's no way to get the right UTC label for 2008-12-31 23:59:60 out of POSIX.

This is somewhat analogous to someone who wants to express 2011-11-06 01:30:00 (America/New_York) with a timestamp. Due to DST, 01:30 happens twice that day in that zone, so should which should it return: 1320557400 or 1320561000? Existing implementations can handle this pretty well, albeit imperfectly. But that's what you get when you have a non-one-to-one mapping.

I think similar solutions could be employed should a zone such as Etc/TAI be added to the TZ database. After all, it's only one second rather than an entire hour. Any difficulty would be in keeping the tables up-to-date, and even that isn't terribly hard with all of us watching for changes.

I still think the original question of "Should TAI be added to TZ?" has not really been addressed here. I can certainly see some cases where it might be useful, provided the caveats above that it's discontinuous at leap seconds and not future-proof. But then again, all of the existing TZ zones are discontinuous (at least in some sense of the word) at leap seconds, and none of the TZ zones are future-proof, as Russia reminded us earlier this year. If we decide TAI should be added, we just have to go with applying the best data we've got into the future (i.e., TAI-UTC = 34s) until something new comes along. I think it'd be more than reasonable to expect anyone who'd actually be using TAI to understand that.