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

[Tim Peters]

...

[TIm]
>> Specifically, a time zone is a function mapping UTC calendar notation
>> to another (possibly identical) calendar notation.

[Alexander]
> 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.