[Datetime-SIG] PEP 495 (Local Time Disambiguation) is ready for pronouncement
chris.barker at noaa.gov
Mon Aug 17 18:58:30 CEST 2015
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
> 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.
Christopher Barker, Ph.D.
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...
More information about the Datetime-SIG