[Datetime-SIG] PEP-0500 (Alternative datetime arithmetic) Was: PEP 495 ... is ready ...
alexander.belopolsky at gmail.com
Thu Aug 20 03:00:50 CEST 2015
On Wed, Aug 19, 2015 at 8:16 PM, Tim Peters <tim.peters at gmail.com> wrote:
> I propose to end the argument about what "time zone" means by
> insisting it means whatever I think it means, and that's the end of it
> Specifically, a time zone is a function mapping UTC calendar notation
> to another (possibly identical) calendar notation.
I would not got a far as allowing say a function that swaps minutes and
seconds in "time zone" definition, but as long as we agree that
datetime.timezone is, umm, a "time zone", I am happy with your definition.
> For some purposes, the destination's idea of "calendar notation"
> includes strings like "America/Chicago" or "CDT"/"CST", and in others
> it may only include a notion of a fixed UTC offset (like "-05:00").
I don't think anyone here denies that there is more than fixed UTC offset
timezones. It just so happened that this is all that CPython ships in the
> All are valid "time zones", and, e.g., someone insisting that their
> idea of calendar notation must magically include a string mnemonically
> distinguishing daylight from standard time is on ground just as solid
> as anyone else.
> Telling them they "shouldn't" insist on that won't work. Showing them
> it's easily obtained by other means also won't work.
I am more optimistic than you are on that. If "include a string
mnemonically distinguishing daylight from standard time" is an actual
requirement for the product that they need to ship, I am sure they will
appreciate seeing that this can be achieved by adding .astimezone() in a
few strategic places.
> Unless, of course, their idea of "time zone" is "how civil time
> actually works" ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Datetime-SIG