Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

References	(19 earlier) <1442257996.253100.383441705.7A0986C7@webmail.messagingengine.com> <CAExdVN=s_V_uz9mSOtp6b6+fKjqLZHArXKUQ-ty5EYkLM5V2qw@mail.gmail.com> <CAP7h-xa3fu5Yo5GGdqDiM-vgxFJnwW9SQYW9Hcm1+Jfpy6csmA@mail.gmail.com> <CAExdVN=TYS-xZWKRy7nVh0_V9SC6-WPh2KPE5E1fN1qd+sNeeA@mail.gmail.com> <CAP7h-xbdx+f2SSYbBCXqzsasTF8kP5hGAnJQtvK9f1z6sPvxhw@mail.gmail.com>
From	Tim Peters <tim.peters@gmail.com>
Date	2015-09-14 15:22 -0500
Subject	Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
Newsgroups	comp.lang.python
Message-ID	<mailman.565.1442262194.8327.python-list@python.org> (permalink)

Show all headers | View raw

[Tim]
>> It depends on how expensive .utcoffset()
>> is, which in turn depends on how the tzinfo author implements it.

[Alex]
> No, it does not.  In most time zones, UTC offset in seconds can be computed
> by C code as a 4-byte integer

Which is a specific implementation of .utcoffset().  Which likely has
nothing to do with how most tzinfo authors will implement _their_
.utcoffset().  For example, look at any tzinfo.utcoffset()
implementation that currently exists ;-)


> faster
> than CPython can look up the .utcoffset method. (At least for times
> within a few years around now.) A programmer who makes it slower should
> be fired.

So any programmer who implements .utcoffset() in Python should be
fired?  That's the only way I can read that.


> Yet I agree,  "'premature optimization' applies at this time."

I'm more worried now about premature firing ;-)

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread

Thread

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo? Tim Peters <tim.peters@gmail.com> - 2015-09-14 15:22 -0500

csiph-web