[Datetime-SIG] What's are the issues?

[Tim Peters]

Have to hit-and-run here (out of time for this for a while):

[Chris Barker]
>> Huh? Now I'm really confused. IIUC, the is_dst flag is required in order to
>> be able to round-trip between UTC and local_time representations.

[Lennart Regebro]
> No, that's not necessary. It's necessary to disambiguate between
> ambiguous datetimes, but you can, like dateutils implementation,
> simply just pick one consistently, and you can round-trip.

is_dst remains necessary to distinguish between ambiguous local times,
just as Chris states:

>> In particular, so the API can support specifying a datetime in a time zone
>> that "happens" twice without ambiguity.

> Yes, but that has now been declared as not desired.

News to me ;-)

> We no longer want datetime to be able to do that.

Of course we do.;  Well, some people do ;-)

> That's only a feature you need or even can have if you want to do
> real time arithmetic over DST changes.

Not so.  It can easily (albeit rarely) arise in cases of pure timezone
conversions.  Conversions have nothing to do with arithmetic.  If I
convert a time in zone X to a time in zone Y that lands in an
ambiguous span in zone Y, without the conversion _also_ setting an
is_dst flag in the destination, it's impossible to reliably convert
the time in zone Y back to zone X again.  Note that it's quite
possible the time we started with was not ambiguous in X's zone, so
without is_dst to tell us which zone-Y time was intended, the
conversion back to zone X may be dead wrong (from X's POV).

Note that ambiguities are also possible in timezones where the _base_
("standard") UTC offset changes over time.  The default conversion
methods currently ignore such possibilities.  There have already been
many other messages suggesting that, because of this, "is_dst" may be
a poor name for the bit of information required,

[and skipping the rest for now because I'm more than out of time now ;-)\