<div dir="ltr">On Sun, Aug 16, 2015 at 7:29 PM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><div class="gmail_extra"><br></div></div></div><div class="gmail_extra">How did we end up bending over this far backwards for leap seconds?<br></div></div></blockquote><div><br></div><div>Are we bending over backwards at all for leap seconds? I don't see where -- at least not in this PEP.<br><br></div><div>But as the un-official  leap-seconds nudge on this list -- I don't think we should bend over backwards to support them. I just think if we can leave open the door to a future implementation without any bending, then we should.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">To me, we're talking about a mapping to POSIX timestamps</div></div></blockquote><div><br></div><div>indeed -- and if you are mapping to POSIX timestamps, it should certainly match what POSIX specifies.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">If you care about leap seconds you should use a different time source, and you shouldn't be using either the time module or the datetime module. </div></blockquote><div><br></div><div>well, not as datetime is currently implemented, anyway, sure.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br>And while I'm at it, I don't think PEP 500 is the answer. </div></div></blockquote><div><br></div><div>I know I really don't like the idea of delegating everything to the tzinfo object, it simply doesn't seem to be the right place for things other than, timezone info / operations.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">If you really want the number of real-world seconds between two datetime values you can write your own difftime() function that consults a leap seconds database.<br><br></div></div></blockquote><div><br></div><div>If I get around to it, I'd like to try a datetime subclass (or duck-typed work-alike) that does leap seconds (with a table, of course). It think it should be doable such that it can inter-opt with the existing timedelta classes and tzinfo objects. Maybe I'm totally wrong, but I guess I'll find out if/when I get around to it.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"></div><div class="gmail_extra">As for how to request timeline arithmetic vs. the other kind ("human"? I forget where our glossary is), that could be done by special-casing in the datetime class using some property (yet to be determined) of the tzinfo subclass or instance; or it could be done using different timedelta-ish classes. PEP 500 seems overly general just so it can also support the leap second case.<br></div></div></blockquote><div><br></div><div>I totally agree -- datetime is where the "how to handle tzinfo for computing deltas" logic is, so it makes sense to keep it there. A flag for what kind of arithmetic you want should be able to handle it.<br><br></div><div>but that's another PEP.<br> <br></div></div>-Chris<br><br>-- <br><div class="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>