[Datetime-SIG] PEP-0500 (Alternative datetime arithmetic) Was: PEP 495 ... is ready ...
tim.peters at gmail.com
Thu Aug 20 03:18:03 CEST 2015
>> 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,
I go that far, but I make no promise about how far I'm willing to go
to _support_ insane calendar notations ;-)
> but as long as we agree that datetime.timezone is, umm, a "time zone",
> I am happy with your definition.
Universal bliss :-)
>> 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.
Which I'll take as proof that I'm older than you ;-)
> 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.
For Pythons already released, yes, they'll appreciate that - although
most people with such a requirement in a serious application is
probably already using pytz, where they've already added pytz's "force
the magical standard/daylight string switch" dance.
I was really talking about a future post-PEP-495 world: nobody is
going to be willing to do _any_ dance to get the strings right after
"timeline arithmetic" is added. Except for me. Because I won't use
timeline arithmetic - I prefer simple named functions for that
purpose. They'll work by magic too.
More information about the Datetime-SIG