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

[Chris Barker - NOAA Federal]

Sent from my iPhone

Chris Barker chris.barker at noaa.gov

What are the issues still to be resolved? [with the PEP]


The is_dst flags added are not implementable, as they aim to make it
possible to do correct timezone conversions, and Guido and Tim have

declared that they don't want that, but that they want to keep the
arithmetic what they call "naive


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.

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

But this is required whether or not you want to support what I'm calling
Calendar operations.

Also, the PEP is about adding useful tzinfo objects to the stdlib, yes? I
agree that tzinfo objects are much less useful without a is_dst flag, but
that is orthogonal to how tzinfo objects work.

Guido and Tim have
declared that they don't want that, but that they want to keep the
arithmetic what they call "naive


 This is why I've been harping on semantics. Apparently I've totally
misunderstood Tim's points ( or you have ;-) ).

As it stands today, time arithmetic such as:

A_datetime + timedelta( days=1)

Means: return a datetime object that represents a point on the time
continuum 24 hours further on.

There is no reason that has to change one bit in order to support time
zones "properly".

All a timezone is is a set of rules for how to map from a point on the time
continuum to our human-friendly, politically and astronomically driven
"calendar" representation. Doing that correctly is really useful in an of
itself.

You are interpreting Tim's "naive time arithmetic" differently than I have
( though his last note did confuse me, and did fit your interpretation), so
I'll try to re-phrase:

The datetime module does, and will always define:

A_datetime + timedelta( days=1)

To mean *BOTH*:

"Move along the time continuum 24 hours."
And
"Move to the same clock time of the next calendar day"

I find this hard to believe, because that can only be true for naive
datetime a, or timezones with no DST and no change of definition. (I.e.
UTC). And yet, the original implementation did provide a hook for a tzinfo
object. Was it never intended to be useful????

BTW, as Tim pointed out (and I at least found it interesting), that
datetime, while encoding the location on the time continuum in calendar
units ( year, month, day, ....), when doing operations, it is essentially
working in "microseconds since year 1". Which, indeed, is what you need to
do to do time arithmetic rationally.


I'll send in a patch to withdraw PEP-431 it later today, I hope.


Sigh. Just saw the PEP update.

Yes, doing calculations in UTC is the best way to go -- using an encoding
that is not continuous for arithmetic would be a nightmare.

Sorry to be late to the party, but I'll take your word for it that doing
the to-from UTC conversion would be difficult with the current
implementation.

-Chris


//Lennart
_______________________________________________
Datetime-SIG mailing list
Datetime-SIG at python.org
https://mail.python.org/mailman/listinfo/datetime-sig
The PSF Code of Conduct applies to this mailing list:
https://www.python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150729/b5fdf9ed/attachment-0001.html>