[Datetime-SIG] PEP 495 (Local Time Disambiguation) is ready for pronouncement

[Chris Barker]

On Sun, Aug 16, 2015 at 7:29 PM, Guido van Rossum <guido at python.org> wrote:

>
> How did we end up bending over this far backwards for leap seconds?
>

Are we bending over backwards at all for leap seconds? I don't see where --
at least not in this PEP.

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.


> To me, we're talking about a mapping to POSIX timestamps
>

indeed -- and if you are mapping to POSIX timestamps, it should certainly
match what POSIX specifies.


> 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.
>

well, not as datetime is currently implemented, anyway, sure.



>
>
> And while I'm at it, I don't think PEP 500 is the answer.
>

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.

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.
>
>
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.


> 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.
>

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.

but that's another PEP.

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150817/96b51238/attachment-0001.html>