<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, 14 May 2018 at 12:17 Chris Angelico <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, May 15, 2018 at 2:05 AM, Chris Barker via Python-ideas<br>
<<a href="mailto:python-ideas@python.org" target="_blank">python-ideas@python.org</a>> wrote:<br>
> But my question is whether high precision timedeltas belongs with "calendar<br>
> time" at all.<br>
><br>
> What with UTC and leap seconds, and all that, it gets pretty ugly, when down<br>
> to the second or sub-second, what a given datetime really means.<br>
<br>
UTC and leap seconds aren't a problem. When there's a leap second, you<br>
have 23:59:60 (or you repeat 23:59:59, if you can't handle second<br>
#60). That's pretty straight-forward, perfectly well-defined.<br></blockquote><div><br></div><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><br></div><div>The ways to resolve this problem are:</div><div>(1) fudge the definition of "exactly 10^8 seconds" to disregard any leap seconds that occur in that time interval in the real world, making it not so exact anymore</div><div>(2) use TAI instead of UTC, as GPS systems do</div><div>(3) leave the relationship between time deltas and calendar time undefined, as some in this thread are suggesting</div><div><br></div></div></div>