TAI zone?

[Tim Parenti]

On Fri, Jul 1, 2011 at 12:48, Guy Harris <guy at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20110701/f5f97ef9/attachment.html