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

Lennart Regebro regebro at gmail.com
Wed Jul 29 18:02:07 CEST 2015


On Wed, Jul 29, 2015 at 5:42 PM, Chris Barker - NOAA Federal
<chris.barker at noaa.gov> wrote:
> 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.

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.

> 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. We no longer want
datetime to be able to do that. That's only a feature you need or even
can have if you want to do real time arithmetic over DST changes.
But the current functionality, and it has been pronounced that this
functionality shall remain, does not allow for that disambiguation. It
assumes that one day is 24 hours at all time, and that DST shall be
ignored. For what is then the dst-flag?

> Also, the PEP is about adding useful tzinfo objects to the stdlib, yes?

Yes, that part is doable, so if somebody wants to resurrect the PEP to
do that they are welcome. I won't.

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

No, that's not what it means. It means "return a datetime object with
the same time, the next day".
That's OK, by itself, unfortunately it also means that "A_datetime +
timedelta(hours=24)" means the same thing, and that's a problem, since
adding 24 hours can result in a datetime object that is 23 to 25 hours
later.

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

Exactly.

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

Exactly the problem. The assumption/definition of one day always being
24 hours breaks reality, in much the same way as assuming pi is 3. And
(as Pratchett fans are aware, doing so opens holes to parallel
universes).

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

Well, doing it in a way that agrees with time outside of datetimes
pi=3 definition is, yes. Otherwise it's reasonably easy, and dateutil
has done it. pytz did implement correct arithmetic, but only by
implementing a function called "normalize()" which corrects for
datetime's mistakes.

//Lennart


More information about the Datetime-SIG mailing list