alexander.belopolsky at gmail.com
Sat Aug 22 21:15:20 CEST 2015
On Sat, Aug 22, 2015 at 2:55 PM, Tim Peters <tim.peters at gmail.com> wrote:
> > Python doesn't need such an [time zone transition point discovery] API.
> Let me be clearer about this. I appreciate that Olson-general
> timezones are a PITA to implement both compactly and efficiently.
> tzinfo internals may want all sorts of internal "helper APIs" to ease
> that burden. The alternative is asking Alexander "and what about this
> year?" for each annoying case, and waiting for him to write a class
> implementing the rules for just the specific year in question ;-)
I don't really mind. I enjoy learning about exotic places and the
timekeeping practices there. (The secret mission behind the killed PEP 500
was to implement the Martian Time.:-)
> Hammering that stuff out is certainly appropriate on this list - it's
> just not in the scope of PEP 495. That's about specifying visible
> results (requirements on tzinfo implementations), and adding a
> user-visible flag requires a PEP. tzinfo internals don't require
> approval from anyone.
Please keep hammering. If we add an additional member to the datetime
objects, I want the new API to be good for the next 20 years and not just
wet the appetite for adding more and more with every Python release. For
example, if anyone can find a place on Earth where 01:30 AM was repeated 3
times in one day - I will be all for changing ltdf type from boolean to
integer. Not because I think it is important to support that one exotic
event, but because if that was done once somewhere it will certainly be
done again somewhere else.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Datetime-SIG