Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #96602 > unrolled thread

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

Started byTim Peters <tim.peters@gmail.com>
First post2015-09-14 15:22 -0500
Last post2015-09-14 15:22 -0500
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

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

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

FromTim Peters <tim.peters@gmail.com>
Date2015-09-14 15:22 -0500
SubjectRe: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
Message-ID<mailman.565.1442262194.8327.python-list@python.org>
[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 ;-)

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web