On Fri, Jul 1, 2011 at 12:48, Guy Harris <guy@alum.mit.edu> wrote:
...but there's no way to have a TAI zone that could convert a POSIX time_t to TAI with localtime() (whether with the Olson code and database with anything else), given that POSIX says "seconds since the Epoch" really means "non-leap seconds since the Epoch".
Then again, as POSIX explicitly admits, there's no way to convert a POSIX time_t to UTC with localtime() 100% of the time.
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. -- Tim Parenti