On Fri, Jul 1, 2011 at 12:48, Guy Harris <span dir="ltr"><<a href="mailto:guy@alum.mit.edu">guy@alum.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<div class="im"><br></div>...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".<br>
<br>Then again, as POSIX explicitly admits, there's no way to convert a POSIX time_t to UTC with localtime() 100% of the time.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div><div>UTC<span class="Apple-tab-span" style="white-space: pre; "> </span><span class="Apple-tab-span" style="white-space: pre; "> </span>TAI<span class="Apple-tab-span" style="white-space: pre; "> </span>TAI-UTC<span class="Apple-tab-span" style="white-space: pre; "> </span>POSIX time_t</div>
<div>2008-12-31 23:59:58<span class="Apple-tab-span" style="white-space: pre; "> </span>2009-01-01 00:00:31<span class="Apple-tab-span" style="white-space: pre; "> </span>33s<span class="Apple-tab-span" style="white-space: pre; "> </span>1230767998</div>
<div>2008-12-31 23:59:59<span class="Apple-tab-span" style="white-space: pre; "> </span>2009-01-01 00:00:32<span class="Apple-tab-span" style="white-space: pre; "> </span>33s<span class="Apple-tab-span" style="white-space: pre; "> </span>1230767999</div>
<div>2008-12-31 23:59:60*<span class="Apple-tab-span" style="white-space: pre; "> </span>2009-01-01 00:00:33<span class="Apple-tab-span" style="white-space: pre; "> </span>33s<span class="Apple-tab-span" style="white-space: pre; "> </span>(depends)</div>
<div>2009-01-01 00:00:00<span class="Apple-tab-span" style="white-space: pre; "> </span>2009-01-01 00:00:34<span class="Apple-tab-span" style="white-space: pre; "> </span>34s<span class="Apple-tab-span" style="white-space: pre; "> </span>1230768000</div>
<div>2009-01-01 00:00:01<span class="Apple-tab-span" style="white-space: pre; "> </span>2009-01-01 00:00:35<span class="Apple-tab-span" style="white-space: pre; "> </span>34s<span class="Apple-tab-span" style="white-space: pre; "> </span>1230768001</div>
</div><div><br></div><div>On Fri, Jul 1, 2011 at 12:51, Guy Harris <span dir="ltr"><<a href="mailto:guy@alum.mit.edu">guy@alum.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<div class="im">> but sometimes two values on one side map to one value on the other side.<br><br></div>...so that there's no way to get the right UTC label for 2008-12-31 23:59:60 out of POSIX.</blockquote></div><div>
<br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>I still think the <b>original question</b> of "Should TAI be added to TZ?" has not really been addressed here. I can certainly see some cases where it <i>might</i> be useful, provided the caveats above that it's discontinuous at leap seconds and not future-proof. But then again, <i>all</i> of the existing TZ zones are discontinuous (at least in some sense of the word) at leap seconds, and <i>none</i> 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.</div>
<div><br></div>--<br>Tim Parenti<br>