tim at timtimeonline.com
Fri Jul 1 17:12:56 UTC 2011
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz