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

[Chris Barker]

On Wed, Jul 29, 2015 at 10:05 AM, Lennart Regebro <regebro at gmail.com> wrote:

> On Wed, Jul 29, 2015 at 7:00 PM, Tim Peters <tim.peters at gmail.com> wrote:
> > is_dst remains necessary to distinguish between ambiguous local times,
> > just as Chris states:
>
> But with the current implementations, those do not exist. datetime
> explicitly and intentionally assume that 1 day always is 24 hours.
> Hence, in the datetime universe, local times can not be ambiguous,


of course they can (and we really ned antoher word -- again, using "day" to
mean two totally different things).

but anyway -- sorry I used teh term "round trip" that isn't quite what I
meant. What I meant was:

"know what location on the time continuum a particular calendar time
represents"

(note that this is more or less convert to UTC)

that can be ambiguous in a DST transition without an is_dst flag.

So if you want to handle time zones with DST (and go both ways), you need
an is_dst flag.

and that has nothign to do with artihmetic or calendar operations -- but
yes, it's is about conversion.

But really does anyone really want to do the ugliness of trying to do time
calculation completely in a time-zone, discontinuous, ugly as hell
encoding???? I think not -- which mean you can't do squat without
converting to-from a clean representation i.e. UTC.

So I say step one is to fully support time zones and the ability to do
"real" time arithmetic and conversion to-from UTC.

Then it's another task to support calendar operations.

Or does something think we really need to be able to compute "this time
tomorrow", but not "24 hours from now"?

-Chris









>
> > 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.
>
> No, you just consistently pick one of the two times in both
> conversions to and from and it will roundtrip just fine.
>
> //Lennart
>



-- 

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/datetime-sig/attachments/20150729/39d39b0f/attachment.html>