[Python-Dev] Status on PEP-431 Timezones

[Chris Barker]

On Mon, Jul 27, 2015 at 2:10 PM, Tim Peters <tim.peters at gmail.com> wrote:


> Guido will never allow any aspect of "leap seconds" into the core,
>

really? that is a shame (and odd) -- it's a trick, because we don't know
what leap seconds will be needed in the future, but other than that, it's
not really any different than leap years, and required for "proper"
conversion to/from calendar description of time (at least for UTC, the GPS
folks have their own ideas about all this).

But leap seconds are the big red herring -- darn few people need them! It's
pretty rare, indeed, to be expressing your time in gregorian dates, and
also care about accuracy down to the seconds over centuries....

> 2. If you're only working in a single timezone that's defined as UTC
> > or a fixed offset from UTC, naive arithmetic is basically all there
> > is.
>
> Yup!
>

and remarkably useful!


> > 5. The problems all arise *only* with timezones whose UTC offset
> > varies depending on the actual time (e.g., timezones that include the
> > transition to DST and back).
>
> Yup.
>

which is a good reason to "store" your datetime in UTC, and do all the math
there.


> > Are we OK to this point? This much comprises what I would class as a
> > "naive" (i.e. 99% of the population ;-)) understanding of datetimes.
> >
> > The stdlib datetime module handles naive datetime values, and
> > fixed-offset timezones, fine, as far as I can see.
>
> It ignores the possibility called #3 above (that some bureaucrat
> changed the name of a fixed-offset time zone despite that the offset
> didn't change).


Should the code ever care about a time zone's name? it seems that two
tzinfo objects should only be considered the same if they ar the same
instance. period. so not sure what the real issue is with (3)

> 2. Arithmetic within a complex timezone. Theoretically, this is simple
> > enough (convert to UTC, do the calculation naively, and convert back).
> > But in practice, that approach doesn't always match user expectations.
>

what reasonable expectation does this not match?


> > So you have 2 mutually incompatible semantic options - 1 day after 4pm
> > is 3pm the following day, or adding 1 day adds 25 hours - either is a
> > viable choice, and either will confuse *some* set of users. This, I
> > think, is the one where all the debate is occurring, and the one that
> > makes my head explode.
>

This is what I"ve been calling (is there a standard name for it?) a
Calendar operation:

" this time the next day" -- that could be 23, 24, or 25 hours, if you are
bridging a DST transition -- but that kind of operation should not be in
the stdlib -- unless, of course, an entire "work with calendar time" lib is
added -- but that's a whole other story.

for a datetime.timedelta -- a day is 24 hours is a day. period, always.

So you can compute "one day from now", which is the same as "24 hours from
now" or 1440 minutes from now, or ...., but you can't compute "this time
tomorrow" -- not with a timedelta, anyway.

Python picked one to make dead easy
> ("naive"), and intended to make the other _possible_ via longer-winded
> (but conceptually straightforward) code.
>

exactly -- you can extract the year, month, day -- add one to the day, and
then go back. But then you'll need to do all the "30 days hath September"
stuff - and leap years, and ...

which is why all that is another ball of wax. And by the way -- doesn't
dateutil have all that?

>  datetime gave us
> > a richer timedelta object and hence has extra problems.
>

it's only a little richer, and doesn't really add problems, just doesn't
solve some common problems...

There's more to it than that.  "Naive time" also wants, e.g.,
> "01:45:00 tomorrow minus 01:45:00 today" to return 24 hours.  Maybe
> the same thing in disguise, though.
>

I think so -- but it's not a "problem" because the datetime module doesn't
have any way to express "tomorrow" anyway.


> > [1] Well, you can, actually - you say that a timedelta of "1 day"
> > means "the same time tomorrow" and if you want 24 hours, you say "24
> > hours" not "1 day". So timedelta(days=1) != timedelta(hours=24) even
> > though they give the same result for every case except arithmetic
> > involving complex timezones.
>

they always give the same result -- even with complex time zones. I don't
think timedelta evey needs to know about timezones at all. timedelta, is
actually really, really simple, all it needs to know is how to translate
various units into its internal representation (days, seconds, microseconds
?)

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150727/59df8d7a/attachment.html>