<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 15, 2018 at 11:21 AM, Rob Speer <span dir="ltr"><<a href="mailto:rspeer@luminoso.com" target="_blank">rspeer@luminoso.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div dir="ltr"><br></div></span><div>I'm sure that the issue of "what do you call the leap second itself" is not the problem that Chris Barker is referring to. The problem with leap seconds is that they create unpredictable differences between UTC and real elapsed time.</div><div><br></div><div>You can represent a timedelta of exactly 10^8 seconds, but if you add it to the current time, what should you get? What UTC time will it be in 10^8 real-time seconds? You don't know, and neither does anybody else, because you don't know how many leap seconds will occur in that time.</div></div></div></blockquote><div><br></div><div>indeed -- even if you only care about the past, where you *could* know the leap seconds -- they are, by their very nature, of second precision -- which means right before leap second occurs, your "time" could be off by up to a second (or a half second?) </div><div><br></div><div>It's kind of like using a carpenter's tape measure to to locate points from a electron microscope scan :-)</div><div><br></div><div>The other issue with leap-seconds is that python's datetime doesn't support them :-)</div><div><br></div><div>And neither do most date-time libraries.</div><div><br></div><div>-CHB</div></div><div><br></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R (206) 526-6959 voice<br>7600 Sand Point Way NE (206) 526-6329 fax<br>Seattle, WA 98115 (206) 526-6317 main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>