[Datetime-SIG] PEP-0500 (Alternative datetime arithmetic) Was: PEP 495 ... is ready ...

[Alexander Belopolsky]

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
> ;-)
>

+1


>
> 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
standard library.


>
> 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.
>

Absolutely right.


>
> 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...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150819/5d423388/attachment.html>