<br><br><div class="gmail_quote">On Thu, Apr 4, 2013 at 11:01 AM, Chris Barker - NOAA Federal <span dir="ltr"><<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, Apr 3, 2013 at 6:02 PM, Mark Wiebe <<a href="mailto:mwwiebe@gmail.com">mwwiebe@gmail.com</a>> wrote:<br>
> On Wed, Apr 3, 2013 at 4:27 PM, Pauli Virtanen <<a href="mailto:pav@iki.fi">pav@iki.fi</a>> wrote:<br>
<br>
</div><div class="im">>> Probably also TAI and UTC/Posix.<br>
>><br>
>> Converting from one format to the other is problematic since<br>
>> all of them (except TAI afaik) require looking things up in<br>
>> regularly updated databases. Not only restricted to conversions,<br>
>> but also arithmetic, `b - a`. Affects also UTC/Posix via leap<br>
>> seconds --- this probably doesn't usually matter, but if we want<br>
>> to be strict, it's not good to ignore the issue.<br>
><br>
><br>
> I think this would be nice. Would it be a stretch to extend the ISO syntax<br>
> with '2013-02-02T03:00:00TAI'?<br>
<br>
</div>Is there no standard for that already -- it's not mentioned in<br>
ISO_8601, but maybe there is something else.<br>
<div class="im"><br>
> One problem with trying to give technically correct answers for the<br>
> UTC/Posix format is that it can't actually represent the leap-second, so a<br>
> datetime64 + timedelta64 could produce an unrepresentable moment in time.<br>
<br>
</div>I'm a bit confused by that -- how it it different than leap-days?<br></blockquote><div><br>There is a rule for leap days, one knows ahead of time when they will occur.<br><br><snip><br><br>Chuck <br></div>
<br></div>