Re: [Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

[Paul Moore ]
>> 
>> As an example, consider an alarm clock. I want it to go off at 7am
>> each morning. I'd feel completely justified in writing
>> tomorrows_alarm = todays_alarm + timedelta(days=1).

[Lennart Regebro ]
> That's a calendar operation made with a timedelta.

It's an instance of single-timezone datetime arithmetic, of the
datetime + timedelta form.  Your examples have been of the same form.
Note that after Paul's

 tomorrows_alarm = todays_alarm + timedelta(days=1)

it's guaranteed that

assert tomorrows_alarm - todays_alarm == timedelta(days=1)

will succeed too.

> The "days" attribute here is indeed confusing as it doesn't mean 1 day,
> it means 24 hours.

Which, in naive arithmetic, are exactly the same thing.  That's
essentially why naive arithmetic is the default:  it doesn't insist on
telling people that everything they know is wrong ;-)  There's nothing
confusing about Paul's example _provided that_ single-timezone
arithmetic is naive.  It works exactly as he intends every time, and
obviously so.

Seriously, try this exercise:  how would you code Paul's example if
"your kind" of arithmetic were in use instead?  For a start, you have
no idea in advance how many hours you may need to add to get to "the
same local time tomorrow".  24 won't always work  Indeed, no _whole_
number of hours may work (according to one source I found, Australia's
Lord Howe Island uses a 30-minute DST adjustment).  So maybe you don't
want to do it by addition.  What then?  Pick apart the year, month and
day components, then simulate "naive arithmetic" by hand?

The point is that there's no _obvious_ way to do it then.  I'd
personally strip off the tzinfo member, leaving a wholly naive
datetime where arithmetic "works correctly" ;-) , add the day, then
attach the original tzinfo member again.

But for a dozen years it's sufficed to do what Paul did.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

On Mon, Jul 27, 2015 at 9:09 AM, Tim Peters  wrote:
> It's an instance of single-timezone datetime arithmetic, of the
> datetime + timedelta form.

No, because in that case it would always move 24 hours, and it
doesn't. It sometimes moves 23 hours or 25 hours, when crossing a DST
border. That is a calendar operation, in the disguise of a datetime
arithmetic.

But this discussion is now moot, if we can't change this, then we
can't change this, and PEP431 is dead. The only reasonable way out if
this mess is a completely new module for dates and times that doesn't
make these kind of fundamental mistakes. I sincerely doubt I have the
time to implement that this decade.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

On Mon, Jul 27, 2015 at 9:09 AM, Tim Peters  wrote:
> But for a dozen years it's sufficed to do what Paul did.

No, it never did "suffice". It's just that people have been doing
various kinds of workarounds to compensate for these design flaws. I
guess they need to continue to do that for the time being.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Paul Moore]

On 27 July 2015 at 08:34, Lennart Regebro  wrote:
> On Mon, Jul 27, 2015 at 9:09 AM, Tim Peters  wrote:
>> But for a dozen years it's sufficed to do what Paul did.
>
> No, it never did "suffice". It's just that people have been doing
> various kinds of workarounds to compensate for these design flaws. I
> guess they need to continue to do that for the time being.

I'm confused by your position. If it's 7am on the clock behind me,
right now, then how (under the model proposed by the PEP) do I find
the datetime value where it will next be 7am on the clock?

I understand your point that "it's a calendar operation", but that
doesn't help me. I still don't know how you want me to *do* the
operation.

Whatever the outcome of this discussion, any PEP needs to explain how
to implement this operation, because at the moment, it's done with
+timedelta(days=1) and that won't be the case under the PEP. I'm not
trying to shoot down your proposal here, just trying to understand it.

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore  wrote:
> I'm confused by your position. If it's 7am on the clock behind me,
> right now, then how (under the model proposed by the PEP) do I find
> the datetime value where it will next be 7am on the clock?

PEP-431 does not propose to implement calendar operations, and hence
does not address that question.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Paul Moore]

On 27 July 2015 at 09:54, Lennart Regebro  wrote:
> On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore  wrote:
>> I'm confused by your position. If it's 7am on the clock behind me,
>> right now, then how (under the model proposed by the PEP) do I find
>> the datetime value where it will next be 7am on the clock?
>
> PEP-431 does not propose to implement calendar operations, and hence
> does not address that question.

OK, I see. But it does propose to remove that operation from datetime.
Thanks for the clarification.

Am I right to think that because you say "implement calendar
operations" this is not, as far as you are aware, something that
already exists in the stdlib (outside of datetime)? I'm certainly not
aware of an alternative way of doing it.

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

On Mon, Jul 27, 2015 at 11:05 AM, Paul Moore  wrote:
> Am I right to think that because you say "implement calendar
> operations" this is not, as far as you are aware, something that
> already exists in the stdlib (outside of datetime)? I'm certainly not
> aware of an alternative way of doing it.

Right, I think you need to use relativedelta (or rrule) from dateutil,
unless you want to do it yourself, which of course in most cases is
quite easy.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Jon Ribbens]

On Mon, Jul 27, 2015 at 01:04:03AM -0500, Tim Peters wrote:
> [Tim]
> >> The Python docs also are quite clear about that all arithmetic within
> >> a single timezone is "naive".  That was intentional.  The _intended_
> >> way to do "aware" arithmetic was always to convert to UTC, do the
> >> arithmetic, then convert back.
> 
> [Lennart]
> > We can't explicitly implement incorrect timezone aware arithmetic and
> > then expect people to not use it.
> 
> Python didn't implement timezone-aware arithmetic at all within a
> single time zone.  Read what I wrote just above.  It implements naive
> arithmetic within a single time zone.

This usage of "time zone" is confusing. As far as I can tell, you
really mean "UTC offset". A time zone would be something like
"Europe/London", which has two different UTC offsets throughout
the year (not to mention other historical weirdnesses), whereas
arithmetic on a "timezone-aware" datetime is only going to work
so long as you don't cross any of the boundaries where the UTC
offset changes.

I agree with you about pretty much everything else about datetime,
just I find the terminology misleading. The only other thing I found
really weird about datetime is how Python 2 had no implementation of
a UTC tzinfo class, despite this being utterly trivial - but it's too
late to do anything about that now, of course.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[R. David Murray]

On Mon, 27 Jul 2015 02:09:19 -0500, Tim Peters  wrote:
> Seriously, try this exercise:  how would you code Paul's example if
> "your kind" of arithmetic were in use instead?  For a start, you have
> no idea in advance how many hours you may need to add to get to "the
> same local time tomorrow".  24 won't always work  Indeed, no _whole_
> number of hours may work (according to one source I found, Australia's
> Lord Howe Island uses a 30-minute DST adjustment).  So maybe you don't
> want to do it by addition.  What then?  Pick apart the year, month and
> day components, then simulate "naive arithmetic" by hand?
> 
> The point is that there's no _obvious_ way to do it then.  I'd
> personally strip off the tzinfo member, leaving a wholly naive
> datetime where arithmetic "works correctly" ;-) , add the day, then
> attach the original tzinfo member again.

I *think* I'd be happy with that solution.

I'm not sure if the opinion of a relatively inexperienced timezone user
(whose head hurts when thinking about these things) is relevant, but in
case it is:

My brief experience with pytz is that it gets this all "wrong".  (Wrong
is in quotes because it isn't wrong, it just doesn't match my use
cases).  If I add a timedelta to a pytz datetime that crosses the DST
boundary, IIRC I get something that still claims it is in the previous
"timezone" (which it therefore seemed to me was really a UTC offset),
and I have to call 'normalize' to get it to be in the correct "timezone"
(UTC offset).  I don't remember what that does to the time, and I have
no intuition about it (I just want it to do the naive arithmetic!)

This makes no sense to me, since I thought a tzinfo object was supposed
to represent the timezone including the DST transitions.  I presume this
comes from the fact that datetime does naive arithmetic and pytz is
trying to paste non-naive arithmetic on top?

So, would it be possible to take the timezone database support from
pytz, and continue to implement naive-single-zone arithmetic the way Tim
proposes, and have it automatically produce the correct UTC offset and
UTC-offset-label afterward, without a normalize call?  I assumed that
was what the PEP was proposing, but I never read it so I can't complain
that I was wrong :)

I have a feeling that I'm completely misunderstanding things, since
tzinfo is still a bit of a mystery to me.

Based on this discussion it seems to me that (1) datetime has to/should
continue to do naive arithmetic and (2) if you need to do non-naive UTC
based calculations (or conversions between timezones) you should be
converting to UTC *anyway* (explicit is better than implicit).  The
addition of the timezone DB would then give us the information to *add*
tools that do conversions between time zones &c.

At Tim says, the issue of disambiguation is separate, and I seem to
recall a couple of proposals from the last time this thread went around
for dealing with that.

--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Steven D'Aprano]

On Mon, Jul 27, 2015 at 10:54:02AM +0200, Lennart Regebro wrote:
> On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore  wrote:
> > I'm confused by your position. If it's 7am on the clock behind me,
> > right now, then how (under the model proposed by the PEP) do I find
> > the datetime value where it will next be 7am on the clock?
> 
> PEP-431 does not propose to implement calendar operations, and hence
> does not address that question.

To me, Paul's example is a datetime operation: you start with a datetime 
(7am today), perform arithmetic on it by adding a period of time (one 
day), and get a datetime as the result (7am tomorrow).

To my naive mind, I would have thought of calendar operations to be 
things like:

- print a calendar;
- add or remove an appointment;
- send, accept or decline an invitation

What do you think calendar operations are, and how do they differ from 
datetime operations? And most importantly, how can we tell them apart?

Thanks,


-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Chris Angelico]

On Tue, Jul 28, 2015 at 12:13 AM, Steven D'Aprano  wrote:
> On Mon, Jul 27, 2015 at 10:54:02AM +0200, Lennart Regebro wrote:
>> On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore  wrote:
>> > I'm confused by your position. If it's 7am on the clock behind me,
>> > right now, then how (under the model proposed by the PEP) do I find
>> > the datetime value where it will next be 7am on the clock?
>>
>> PEP-431 does not propose to implement calendar operations, and hence
>> does not address that question.
>
> To me, Paul's example is a datetime operation: you start with a datetime
> (7am today), perform arithmetic on it by adding a period of time (one
> day), and get a datetime as the result (7am tomorrow).
>
> To my naive mind, I would have thought of calendar operations to be
> things like:
>
> - print a calendar;
> - add or remove an appointment;
> - send, accept or decline an invitation
>
> What do you think calendar operations are, and how do they differ from
> datetime operations? And most importantly, how can we tell them apart?
>

Concrete example: I meet with my students on a weekly basis, with the
scheduled times being defined in the student's timezone. For instance,
I might meet with a student every Thursday at 1PM America/Denver. When
there's a DST switch in that timezone, our meetings will be either 167
or 169 hours apart. I want a script that waits until five minutes
before my next meeting (with anyone) and then plays "Let It Go" in a
randomly-selected language. How would I go about doing this with pytz
and/or datetime? How would I do this under the new proposal? (FWIW, I
currently have exactly such a script, but it's backed by my Google
Calendar. I'm seriously considering rewriting it to use a simple text
file as its primary source, in which case my options are Python
(datetime+pytz) and Pike (built-in Calendar module). This does not
strike me as an altogether unusual kind of script to write.)

And no, Steve, you're not the only one. But maybe the entire thread
should completely halt until there's a PEP draft to discuss, and
*then* reopen on -ideas.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Steve Dower]

Am I the only one feeling like this entire thread should be moved to 
python-ideas at this point?

Top-posted from my Windows Phone

From: Steven D'Aprano
Sent: ‎7/‎27/‎2015 7:14
To: python-dev@python.org
Subject: Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 10:54:02AM +0200, Lennart Regebro wrote:
> On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore  wrote:
> > I'm confused by your position. If it's 7am on the clock behind me,
> > right now, then how (under the model proposed by the PEP) do I find
> > the datetime value where it will next be 7am on the clock?
>
> PEP-431 does not propose to implement calendar operations, and hence
> does not address that question.

To me, Paul's example is a datetime operation: you start with a datetime
(7am today), perform arithmetic on it by adding a period of time (one
day), and get a datetime as the result (7am tomorrow).

To my naive mind, I would have thought of calendar operations to be
things like:

- print a calendar;
- add or remove an appointment;
- send, accept or decline an invitation

What do you think calendar operations are, and how do they differ from
datetime operations? And most importantly, how can we tell them apart?

Thanks,


--
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

On Mon, Jul 27, 2015 at 3:59 PM, R. David Murray  wrote:
> I'm not sure if the opinion of a relatively inexperienced timezone user
> (whose head hurts when thinking about these things) is relevant, but in
> case it is:
>
> My brief experience with pytz is that it gets this all "wrong".  (Wrong
> is in quotes because it isn't wrong, it just doesn't match my use
> cases).  If I add a timedelta to a pytz datetime that crosses the DST
> boundary, IIRC I get something that still claims it is in the previous
> "timezone" (which it therefore seemed to me was really a UTC offset),
> and I have to call 'normalize' to get it to be in the correct "timezone"
> (UTC offset).

Right.

> I don't remember what that does to the time, and I have
> no intuition about it (I just want it to do the naive arithmetic!)

But what is it that you expect?

That you add one hour to it, and the datetime moves forward one hour
in actual time? That's doable, but during certain circumstance this
may mean that you go from 1AM to 1AM, or from 1AM to 3AM.

Or do you expect that adding one hour will increase the hour count
with one, ie that the "wall time" increases with one hour? This may
actually leave you with a datetime that does not exist, so that is not
something you can consistently do.

Dates and times are tricky, and especially with DST it is simply
possible to make an implementation that is intuitive in all cases to
those who don't know about the problems. What we should aim for is an
implementation that is easy to understand and hard to make errors
with.

> This makes no sense to me, since I thought a tzinfo object was supposed
> to represent the timezone including the DST transitions.  I presume this
> comes from the fact that datetime does naive arithmetic and pytz is
> trying to paste non-naive arithmetic on top?

Exactly.

> So, would it be possible to take the timezone database support from
> pytz, and continue to implement naive-single-zone arithmetic the way Tim
> proposes, and have it automatically produce the correct UTC offset and
> UTC-offset-label afterward, without a normalize call?

That depends on your definition of "correct".

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Nick Coghlan]

On 28 July 2015 at 00:27, Steve Dower  wrote:
> Am I the only one feeling like this entire thread should be moved to
> python-ideas at this point?

Since this is an area where the discussion of implementation details
and the discussion of the developer experience can easily end up at
cross purposes, I'm wondering if there may be value in actually
splitting those two discussions into different venues by creating a
datetime-sig, and specifically inviting the pytz and dateutil
developers to participate in the SIG as well.

The traffic on a similarly niche group like import-sig is only
intermittent, but it means that by the time we bring suggestions to
python-ideas or python-dev, we've already thrashed out the low level
arcana and know that whatever we're proposing *can* be made to work,
leaving the core lists to focus on the question of whether or not the
change *should* be made.

Whether or not to do that would be up to the folks with a specific
interest in working with dates and times, though.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

On Mon, Jul 27, 2015 at 4:13 PM, Steven D'Aprano  wrote:
> To me, Paul's example is a datetime operation: you start with a datetime
> (7am today), perform arithmetic on it by adding a period of time (one
> day), and get a datetime as the result (7am tomorrow).

Well, OK, let's propose these wordings: It looks like a date
operation, ie, add one to the date, but in reality it's a time
operation, ie add 86400 seconds to the time. These things sound
similar but are very different.

I called it a "calendar" operation, because these operation include
such things as "add one year", where you expect to get the 27th of
July 2016, but you will get the 26th if you use a timedelta, because
2016 is a leap year. So we need to separate date (or calendar)
operations from time operations. The same thing goes with months, add
30 days, and you'll sometimes get the same result as if you add one
month and sometimes not.

timedelta adds time, not days, month or years. Except when you cross a
DST border where it suddenly, surprisingly and intentionally may add
more or less time than you told it to.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

On Mon, Jul 27, 2015 at 4:27 PM, Steve Dower  wrote:
> Am I the only one feeling like this entire thread should be moved to
> python-ideas at this point?

Well, there isn't any idea to discuss. :-) It's just an explanation of
the problem space. Perhaps it should be moved somewhere else though.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

On Mon, Jul 27, 2015 at 4:45 PM, Nick Coghlan  wrote:
> On 28 July 2015 at 00:27, Steve Dower  wrote:
>> Am I the only one feeling like this entire thread should be moved to
>> python-ideas at this point?
>
> Since this is an area where the discussion of implementation details
> and the discussion of the developer experience can easily end up at
> cross purposes, I'm wondering if there may be value in actually
> splitting those two discussions into different venues by creating a
> datetime-sig, and specifically inviting the pytz and dateutil
> developers to participate in the SIG as well.

+1 for that.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Paul Moore]

On 27 July 2015 at 14:59, R. David Murray  wrote:
> I have a feeling that I'm completely misunderstanding things, since
> tzinfo is still a bit of a mystery to me.

You're not the only one :-)

I think the following statements are true. If they aren't, I'd
appreciate clarification. I'm going to completely ignore leap seconds
in the following - I hope that's OK, I don't understand leap seconds
*at all* and I don't work in any application areas where they are
relevant (to my knowledge) so I feel that for my situation, ignoring
them (and being able to) is reasonable.

Note that I'm not talking about internal representations - this is
purely about user-visible semantics.

1. "Naive" datetime arithmetic means treating a day as 24 hours, an
hour as 60 minutes, etc. Basically base-24/60/60 arithmetic.
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.
3. Converting between (fixed offset) timezones is a separate issue
from calculation - but it's nothing more than applying the relevant
offsets.
4. Calculations involving 2 different timezones (fixed-offset ones as
above) is like any other exercise involving values on different
scales. Convert both values to a common scale (in this case, a common
timezone) and do the calculation there. Simple enough.
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).

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. (I'm not sure that
the original implementation included fixed-offset tzinfo objects, but
the 3.4 docs say they are there now, so that's fine).

Looking at the complicated cases, the only ones I'm actually aware of
in practice are the ones that switch to DST and back, so typically
have two offsets that differ by an hour, switching between the two at
some essentially arbitrary points. If there are other more complex
forms of timezone, I'd like to never need to know about them, please
;-)

The timezones we're talking about here are things like
"Europe/London", not "GMT" or "BST" (the latter two are fixed-offset).

There are two independent issues with complex timezones:

1. Converting to and from them. That's messy because the conversion to
UTC needs more information than just the date & time (typically, for
example, there is a day when 01:45:00 maps to 2 distinct UTC times).
This is basically the "is_dst" bit that Tim discussed in an earlier
post. The semantic issue here is that users typically say "01:45" and
it never occurs to them to even think about *which* 01:45 they mean.
So recovering that extra information is hard (it's like dealing with
byte streams where the user didn't provide details of the text
encoding used). Once we have the extra information, though, doing
conversions is just a matter of applying a set of rules.

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

It seems to me that the problem is that for this latter issue, it's
the *timedelta* object that's not rich enough. You can't say "add 1
day, and by 1 day I mean keep the same time tomorrow" as opposed to
"add 1 day, and by that I mean 24 hours"[1]. In some ways, it's
actually no different from the issue of adding 1 month to a date
(which is equally ill-defined, but people "know what they mean" to
just as great an extent). Python bypasses the latter by not having a
timedelta for "a month". C (and the time module) bypasses the former
by limiting all time offsets to numbers of seconds - datetime gave us
a richer timedelta object and hence has extra problems.

I don't have any solutions to this final issue. But hopefully the
above analysis (assuming it's accurate!) helps clarify what the actual
debate is about, for those bystanders like me who are interested in
following the discussion. With luck, maybe it also gives the experts
an alternative perspective from which to think about the problem - who
knows?

Paul

[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. Is that what Lennart has been trying to
say 

Re: [Python-Dev] Status on PEP-431 Timezones

[R. David Murray]

On Mon, 27 Jul 2015 16:37:47 +0200, Lennart Regebro  wrote:
> On Mon, Jul 27, 2015 at 3:59 PM, R. David Murray  
> wrote:
> > I don't remember what that does to the time, and I have
> > no intuition about it (I just want it to do the naive arithmetic!)
> 
> But what is it that you expect?

"I just want it to do the naive arithmetic"

> > So, would it be possible to take the timezone database support from
> > pytz, and continue to implement naive-single-zone arithmetic the way Tim
> > proposes, and have it automatically produce the correct UTC offset and
> > UTC-offset-label afterward, without a normalize call?
> 
> That depends on your definition of "correct".

If I have a time X on date Y in timezone Z, it is either this UTC offset
or that UTC offset, depending on what the politicians decided.  Couple
that with naive arithmetic, and I think you have something easily
understandable from the end user perspective, and useful for a wide
variety (but far from all) use cases.

I'll stop now :)

--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Building python 2.7.10 for Windows from source

[Mark Kelley]

Thanks, that got me a bit further.  Now I'm wondering how I figure out
which version of tcl,tk and Tix actually got built with the 2.7.10
installer.  Tools\buildbot\external.bat conflicts with the versions
found in PC\build_tkinter.py, and the version in
PC\VS8.0\build_tkinter.py.

I am assuming the buildbot script is the one that's actually, used?  I
would submit a patch to clean some of this up, but sounds as though
it's in the pipeline.

On Fri, Jul 24, 2015 at 2:46 PM, Zachary Ware
 wrote:
> On Jul 24, 2015 8:30 AM, "Mark Kelley"  wrote:
>>
>> I have been using Python for some time but it's been a decade since
>> I've tried to build it from source, back in the 2.4 days.  Things seem
>> to have gotten a little more complicated now.
>>
>> I've read through the PCBuild/README file and got most stuff
>> compiling.  I find it a little odd that there are special instructions
>> for the building the release version of tcl/tk.  Is that what the
>> developers actually do when they cut a release, or is there some
>> other, top-level script that does this automatically? It just seems
>> odd.
>
> That used to be standard procedure, yes. However, I just recently backported
> the project files from 3.5, which include project files for building Tcl/Tk
> and Tix, in both Debug and Release configurations, so I may have missed some
> stuff that could be removed from PCbuild/readme.txt. You do need some extra
> stuff to build 2.7 with its new project files, though (which i know is now
> covered in readme.txt). There hasn't been a release with those project files
> yet though, they're just in the hg repo.
>
>> Anyhow, my specific question is around the distutils wininst stubs,
>> provided as binaries in the release tarball.  Where can I find the
>> source files that those binaries are built from?
>
> I believe the source for those is in PC/bdist_wininst/, or some very similar
> path.
>
> Hope this helps,
> --
> Zach
> (On a phone)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Ryan Hiebert]

> On Jul 27, 2015, at 9:13 AM, Steven D'Aprano  wrote:
> 
> On Mon, Jul 27, 2015 at 10:54:02AM +0200, Lennart Regebro wrote:
>> On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore  wrote:
>>> I'm confused by your position. If it's 7am on the clock behind me,
>>> right now, then how (under the model proposed by the PEP) do I find
>>> the datetime value where it will next be 7am on the clock?
>> 
>> PEP-431 does not propose to implement calendar operations, and hence
>> does not address that question.
> 
> To me, Paul's example is a datetime operation: you start with a datetime 
> (7am today), perform arithmetic on it by adding a period of time (one 
> day), and get a datetime as the result (7am tomorrow).
> 
> To my naive mind, I would have thought of calendar operations to be 
> things like:
> 
> - print a calendar;
> - add or remove an appointment;
> - send, accept or decline an invitation
> 
> What do you think calendar operations are, and how do they differ from 
> datetime operations? And most importantly, how can we tell them apart?

The way I interpreted it is that "calendar operations" require knowledge of 
events like daylight savings time that require a more complete knowledge of the 
calendar, rather than just a naive notion of what a date and time are.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Paul Moore]

On 27 July 2015 at 15:37, Lennart Regebro  wrote:
> That you add one hour to it, and the datetime moves forward one hour
> in actual time? That's doable, but during certain circumstance this
> may mean that you go from 1AM to 1AM, or from 1AM to 3AM.
>
> Or do you expect that adding one hour will increase the hour count
> with one, ie that the "wall time" increases with one hour? This may
> actually leave you with a datetime that does not exist, so that is not
> something you can consistently do.

OK, that pretty much validates what I thought might be the case at the
end of my recent lengthy email. What you're saying is that the idea of
a timedelta is insufficiently rich here - just saying "1 hour" doesn't
give you enough information to know which of the two expectations the
user has. (The fact that one of those expectations isn't viable is not
actually relevant here).

OK, I see what your point is now. No idea how to solve it, but at
least I understand what you're getting at (I think). Thanks for not
giving up on the thread!

Does thinking of the problem in terms of timedeltas not containing
enough information to make a_time + a_timedelta a well-defined
operation if a_time uses a non-fixed-offset timezone, make it any
easier to find a way forward?

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[MRAB]

On 2015-07-27 15:46, Lennart Regebro wrote:

On Mon, Jul 27, 2015 at 4:13 PM, Steven D'Aprano  wrote:

To me, Paul's example is a datetime operation: you start with a datetime
(7am today), perform arithmetic on it by adding a period of time (one
day), and get a datetime as the result (7am tomorrow).


Well, OK, let's propose these wordings: It looks like a date
operation, ie, add one to the date, but in reality it's a time
operation, ie add 86400 seconds to the time. These things sound
similar but are very different.

I called it a "calendar" operation, because these operation include
such things as "add one year", where you expect to get the 27th of
July 2016, but you will get the 26th if you use a timedelta, because
2016 is a leap year. So we need to separate date (or calendar)
operations from time operations. The same thing goes with months, add
30 days, and you'll sometimes get the same result as if you add one
month and sometimes not.


Also, if you "add one year" to 29 February 2016, what date do you get?


timedelta adds time, not days, month or years. Except when you cross a
DST border where it suddenly, surprisingly and intentionally may add
more or less time than you told it to.



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

On Mon, Jul 27, 2015 at 5:12 PM, Paul Moore  wrote:
> Does thinking of the problem in terms of timedeltas not containing
> enough information to make a_time + a_timedelta a well-defined
> operation if a_time uses a non-fixed-offset timezone, make it any
> easier to find a way forward?

Well, I think it is a well-defined operation, but that datetime
currently does it wrongly, to be honest. Adding 3600 seconds to a
datetime should move that datetime 3600 seconds forward at all time. I
just do not see a usecase for doing anything else, to be honest. But
if somebody has one, I'm all ears.

The problem here is that the issue of "get the next day" has been
mixed into timedeltas, when it in my opinion is an entirely different
issue that should be kept separate from timedeltas.

It is possible to implement something so that you can both have
"realtimedeltas" and "walltimedeltas" where adding one hour might give
you two hours (or an error) but as per above I can't think of a
usecase.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[MRAB]

On 2015-07-27 15:59, Paul Moore wrote:

On 27 July 2015 at 14:59, R. David Murray  wrote:

I have a feeling that I'm completely misunderstanding things, since
tzinfo is still a bit of a mystery to me.


You're not the only one :-)

I think the following statements are true. If they aren't, I'd
appreciate clarification. I'm going to completely ignore leap seconds
in the following - I hope that's OK, I don't understand leap seconds
*at all* and I don't work in any application areas where they are
relevant (to my knowledge) so I feel that for my situation, ignoring
them (and being able to) is reasonable.

Note that I'm not talking about internal representations - this is
purely about user-visible semantics.


Would it help if it was explicit and we had LocalDateTime and
UTCDateTime?


1. "Naive" datetime arithmetic means treating a day as 24 hours, an
hour as 60 minutes, etc. Basically base-24/60/60 arithmetic.
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.
3. Converting between (fixed offset) timezones is a separate issue
from calculation - but it's nothing more than applying the relevant
offsets.
4. Calculations involving 2 different timezones (fixed-offset ones as
above) is like any other exercise involving values on different
scales. Convert both values to a common scale (in this case, a common
timezone) and do the calculation there. Simple enough.
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).

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. (I'm not sure that
the original implementation included fixed-offset tzinfo objects, but
the 3.4 docs say they are there now, so that's fine).

Looking at the complicated cases, the only ones I'm actually aware of
in practice are the ones that switch to DST and back, so typically
have two offsets that differ by an hour, switching between the two at
some essentially arbitrary points. If there are other more complex
forms of timezone, I'd like to never need to know about them, please
;-)

The timezones we're talking about here are things like
"Europe/London", not "GMT" or "BST" (the latter two are fixed-offset).

There are two independent issues with complex timezones:

1. Converting to and from them. That's messy because the conversion to
UTC needs more information than just the date & time (typically, for
example, there is a day when 01:45:00 maps to 2 distinct UTC times).
This is basically the "is_dst" bit that Tim discussed in an earlier
post. The semantic issue here is that users typically say "01:45" and
it never occurs to them to even think about *which* 01:45 they mean.
So recovering that extra information is hard (it's like dealing with
byte streams where the user didn't provide details of the text
encoding used). Once we have the extra information, though, doing
conversions is just a matter of applying a set of rules.

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

It seems to me that the problem is that for this latter issue, it's
the *timedelta* object that's not rich enough. You can't say "add 1
day, and by 1 day I mean keep the same time tomorrow" as opposed to
"add 1 day, and by that I mean 24 hours"[1]. In some ways, it's
actually no different from the issue of adding 1 month to a date
(which is equally ill-defined, but people "know what they mean" to
just as great an extent). Python bypasses the latter by not having a
timedelta for "a month". C (and the time module) bypasses the former
by limiting all time offsets to numbers of seconds - datetime gave us
a richer timedelta object and hence has extra problems.

I don't have any solutions to this final issue. But hopefully the
above analysis (assuming it's accurate!) helps clarify what the actual
debate is about, for those bystanders like me who are interested in
following the discussion. With luck, maybe it also gives the experts
an alternative perspective from which to think about the problem - who
knows?

Paul

[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 s

Re: [Python-Dev] Status on PEP-431 Timezones

[Paul Moore]

On 27 July 2015 at 16:26, MRAB  wrote:
>> Note that I'm not talking about internal representations - this is
>> purely about user-visible semantics.
>>
> Would it help if it was explicit and we had LocalDateTime and
> UTCDateTime?

I don't see how. Why should I care about the internal representation?
Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Ryan Hiebert]

> On Jul 27, 2015, at 10:37 AM, Alexander Belopolsky 
>  wrote:
> 
> On the other hand, these rare events are not that different from more or less 
> regular DST
> transitions.  You still have either a non-existent or ambiguous local times 
> interval and
> you can resolve the ambiguity by adding 1 bit of information.  The only 
> question is what
> should we call the flag that will supply that information?  IMO, "isdst" is a 
> wrong name
> for dealing with the event I described above.

While I see your point that isdst is the wrong name in that it doesn't describe 
what's actually happening in all cases, it is the most well known instance of 
the issue, and I personally think that using isdst for the other cases makes 
sense, and that they would disambiguate in the same direction that it would in 
a dst transition of the same type (clocks forward or backward).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Mon, Jul 27, 2015 at 10:59 AM, Paul Moore  wrote:

> The semantic issue here is that users typically say "01:45" and
> it never occurs to them to even think about *which* 01:45 they mean.
> So recovering that extra information is hard (it's like dealing with
> byte streams where the user didn't provide details of the text
> encoding used). Once we have the extra information, though, doing
> conversions is just a matter of applying a set of rules.
>

It is slightly more complicated than that.  There are locations (even in
the US, I've heard)
where clocks have been moved back for reasons other than DST.  I described
one such
example in my earlier post [1].  On July 1, 1990, at 2AM, the people of
Ukraine celebrated
their newly acquired independence by moving their clocks  back to 1AM thus
living
through "1990-07-01T01:45" local time twice.  This happened in the middle
of summer and
daylight savings time was in effect before and after the transition, so you
cannot use isdst
to disambiguate between the first and the second "01:45".

On the other hand, these rare events are not that different from more or
less regular DST
transitions.  You still have either a non-existent or ambiguous local times
interval and
you can resolve the ambiguity by adding 1 bit of information.  The only
question is what
should we call the flag that will supply that information?  IMO, "isdst" is
a wrong name
for dealing with the event I described above.

[1]: https://mail.python.org/pipermail/python-dev/2015-April/139099.html
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Mon, Jul 27, 2015 at 11:42 AM, Ryan Hiebert  wrote:

> > On Jul 27, 2015, at 10:37 AM, Alexander Belopolsky <
> alexander.belopol...@gmail.com> wrote:
> >
> > On the other hand, these rare events are not that different from more or
> less regular DST
> > transitions.  You still have either a non-existent or ambiguous local
> times interval and
> > you can resolve the ambiguity by adding 1 bit of information.  The only
> question is what
> > should we call the flag that will supply that information?  IMO, "isdst"
> is a wrong name
> > for dealing with the event I described above.
>
> While I see your point that isdst is the wrong name in that it doesn't
> describe what's actually happening in all cases, it is the most well known
> instance of the issue, and I personally think that using isdst for the
> other cases makes sense, and that they would disambiguate in the same
> direction that it would in a dst transition of the same type (clocks
> forward or backward).


Well, my specific proposal in [1] was to also change the semantics.  The
proposed "which" flag would have the following
meaning:

  1. If local time is valid and unambiguous, "which" is ignored.
  2. If local time is ambiguous, which=0 means the first and which=1 means
the second (chronologically).
  3. If local time is invalid, which=0 means the time extrapolated from
before the transition and
  which = 1 means the time extrapolated from after the transition.

Note that these rules have some nice properties: if t is ambiguous, UTC(t,
which=0) <  UTC(t, which=1)
and if t is invalid, UTC(t, which=0) > UTC(t, which=1).  This property can
be used to take different
actions in those cases.  The result for ambiguous t and which=0 has a
natural interpretation as time
specified by a user not aware of the clock change.

I think these rules are simpler and more natural than those for isdst which
takes 3 values: 0, 1 and -1 and
the rules for -1 vary between implementations.  Under my proposal
unspecified "which" means which=0.

[1]: https://mail.python.org/pipermail/python-dev/2015-April/139099.html
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Nikolaus Rath]

On Jul 27 2015, Lennart Regebro  wrote:
> That you add one hour to it, and the datetime moves forward one hour
> in actual time? That's doable, but during certain circumstance this
> may mean that you go from 1AM to 1AM, or from 1AM to 3AM.
>
> Or do you expect that adding one hour will increase the hour count
> with one, ie that the "wall time" increases with one hour? This may
> actually leave you with a datetime that does not exist, so that is not
> something you can consistently do.

Apologies for asking yet another dumb question about this, but I have
the impression that a lot of other people are struggling with the basics
here too.

Can you tell us which of the two operations datetime currently
implements?

And when people talk about explicitly converting to UTC and back, does
that mean that if you're (again, with the current implementation)
converting to UTC, *then* add the one hour, and then convert back, you
get the other operation (that you don't get when you directly add 1
day)?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

On Mon, Jul 27, 2015 at 6:15 PM, Nikolaus Rath  wrote:
> On Jul 27 2015, Lennart Regebro  wrote:
>> That you add one hour to it, and the datetime moves forward one hour
>> in actual time? That's doable, but during certain circumstance this
>> may mean that you go from 1AM to 1AM, or from 1AM to 3AM.
>>
>> Or do you expect that adding one hour will increase the hour count
>> with one, ie that the "wall time" increases with one hour? This may
>> actually leave you with a datetime that does not exist, so that is not
>> something you can consistently do.
>
> Apologies for asking yet another dumb question about this, but I have
> the impression that a lot of other people are struggling with the basics
> here too.
>
> Can you tell us which of the two operations datetime currently
> implements?

It's intended that the first one is implemented, meaning that
datetime.now() + timedelta(hours=24) can result in a datetime
somewhere between 23 and 25 hours into the future. Or well, any
amount, in theory, I guess some changes are more than an hour, but
that's very unusual.

> And when people talk about explicitly converting to UTC and back, does
> that mean that if you're (again, with the current implementation)
> converting to UTC, *then* add the one hour, and then convert back, you
> get the other operation (that you don't get when you directly add 1
> day)?

Yes, exactly.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Mon, Jul 27, 2015 at 12:15 PM, Nikolaus Rath  wrote:

> On Jul 27 2015, Lennart Regebro  wrote:
> > That you add one hour to it, and the datetime moves forward one hour
> > in actual time? That's doable, but during certain circumstance this
> > may mean that you go from 1AM to 1AM, or from 1AM to 3AM.
> >
> > Or do you expect that adding one hour will increase the hour count
> > with one, ie that the "wall time" increases with one hour? This may
> > actually leave you with a datetime that does not exist, so that is not
> > something you can consistently do.
>
> Apologies for asking yet another dumb question about this, but I have
> the impression that a lot of other people are struggling with the basics
> here too.
>

I believe your questions are addressed to Lennart, but let me offer
my answer to the first:

>
> Can you tell us which of the two operations datetime currently
> implements?


The first one, but not as directly as one might wish.  (I think the
situation
is similar to that of pytz's normalize(), but I am not an expert on pytz.)

>>> t = datetime(2014,11,2,5,tzinfo=timezone.utc).astimezone()
>>> t.strftime("%D %T%z %Z")
'11/02/14 01:00:00-0400 EDT'
>>> (t+timedelta(hours=1)).astimezone().strftime("%D %T%z %Z")
'11/02/14 01:00:00-0500 EST'
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Burning down the backlog.

[Carol Willing]

On 7/26/15 6:37 PM, R. David Murray wrote:

On Sun, 26 Jul 2015 22:59:51 +0100, Paul Moore  wrote:

On 26 July 2015 at 16:39, Berker PeksaÄŸ  wrote:

So, I'm hoping Carol will take what I've written above and turn it into
updates for the devguide (assuming no one disagrees with what I've said :)

David, I'm happy to try to incorporate your detailed steps into the 
devguide.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Mon, Jul 27, 2015 at 12:30 PM, Lennart Regebro  wrote:

> On Mon, Jul 27, 2015 at 6:15 PM, Nikolaus Rath  wrote:
> > On Jul 27 2015, Lennart Regebro  wrote:
>
(The *first* option)

> >> That you add one hour to it, and the datetime moves forward one hour
> >> in actual time? That's doable, but during certain circumstance this
> >> may mean that you go from 1AM to 1AM, or from 1AM to 3AM.
> >>
>
(The *second* option)

> >> Or do you expect that adding one hour will increase the hour count
> >> with one, ie that the "wall time" increases with one hour? ...
> > Can you tell us which of the two operations datetime currently
> > implements?
>
> It's intended that the first one is implemented, meaning that
> datetime.now() + timedelta(hours=24) can result in a datetime
> somewhere between 23 and 25 hours into the future.


I think this describes what was originally your *second*, not *first*
option. It
will also help if you focus on one use case at a time.  Your original
example
dealt with adding 1 hour, but now you switch to adding 24.

In my previous email, I explained what is currently doable using the
datetime
module:

>>> t = datetime(2014,11,2,5,tzinfo=timezone.utc).astimezone()
>>> t.strftime("%D %T%z %Z")
'11/02/14 01:00:00-0400 EDT'
>>> (t+timedelta(hours=1)).astimezone().strftime("%D %T%z %Z")
'11/02/14 01:00:00-0500 EST'

Is this your *first* or your *second* option?  Note that this is not what
is "intended".  This is an actual Python 3.4.3 session.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

On Mon, Jul 27, 2015 at 6:42 PM, Alexander Belopolsky
 wrote:
> I think this describes what was originally your *second*, not *first*
> option.

Yes, you are absolutely correct, I didn't read my own description of
the options carefully enough.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Paul Moore]

On 27 July 2015 at 17:30, Lennart Regebro  wrote:
>> Apologies for asking yet another dumb question about this, but I have
>> the impression that a lot of other people are struggling with the basics
>> here too.
>>
>> Can you tell us which of the two operations datetime currently
>> implements?
>
> It's intended that the first one is implemented, meaning that
> datetime.now() + timedelta(hours=24) can result in a datetime
> somewhere between 23 and 25 hours into the future. Or well, any
> amount, in theory, I guess some changes are more than an hour, but
> that's very unusual.

Maybe that's what the PEP intends. But the stdlib as currently
implemented simply adds the appropriate number to the relevant field
(i.e., "increase the hour count with one").

It's not possible to detect the difference between these two using
only stdlib timezones, though, as those are all fixed-offset.

Both Tim and I have pointed out that Guido's original intention was
precisely what is implemented, for better or worse. What Guido's view
was on DST-aware timezones and whether the behaviour was appropriate
for those, I don't know personally (maybe Tim does). It may well be
that it was "let's not think about it for now".

If we can ever straighten out what the question is, maybe Guido can
chip in and answer it :-)

Paul

PS Ideally, Guido could pop into his time machine and fix the whole
issue at source. But apparently he can't, because the time machine
isn't DST-aware...
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Paul Moore]

On 27 July 2015 at 15:57, Ronald Oussoren  wrote:
> IMHO “+ 1 days” and “+ 24 hours” are two different things.  Date
> arithmetic is full of messy things like that.  “+ 1 month” is another
> example of that (which the datetime module punts completely
> and can be a source of endless bikeshidding).

Precisely.
Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Ronald Oussoren]

> On 27 Jul 2015, at 04:04, Tim Peters  wrote:
> 
> 
>> As an example, consider an alarm clock. I want it to go off at 7am
>> each morning. I'd feel completely justified in writing tomorrows_alarm
>> = todays_alarm + timedelta(days=1).
>> 
>> If the time changes to DST overnight, I still want the alarm to go off
>> at 7am. Even though +1 day is in this case actually + 25 (or is it
>> 23?) hours. That's the current semantics.
> 
> There was a long list of use cases coming to the same conclusion.  The
> current arithmetic allows uniform patterns in local time to be coded
> in uniform, straightforward ways.  Indeed, in "the obvious" ways.  The
> alternative behavior favors uniform patterns in UTC, but who cares?
> ;-)  Few local clocks show UTC.  Trying to code uniform local-time
> behaviors using "aware arithmetic" (which is uniform in UTC. but may
> be "lumpy" in local time) can be a nightmare.
> 
> The canonical counterexample is a nuclear reactor that needs to be
> vented every 24 hours.  To which the canonical rejoinder is that the
> programmer in charge of that system is criminally incompetent if
> they're using _any_ notion of time other than UTC ;-)

IMHO “+ 1 days” and “+ 24 hours” are two different things.  Date 
arithmetic is full of messy things like that.  “+ 1 month” is another
example of that (which the datetime module punts completely
and can be a source of endless bikeshidding).

Ronald


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Mark Lawrence]

On 27/07/2015 15:45, Nick Coghlan wrote:

On 28 July 2015 at 00:27, Steve Dower  wrote:

Am I the only one feeling like this entire thread should be moved to
python-ideas at this point?


Since this is an area where the discussion of implementation details
and the discussion of the developer experience can easily end up at
cross purposes, I'm wondering if there may be value in actually
splitting those two discussions into different venues by creating a
datetime-sig, and specifically inviting the pytz and dateutil
developers to participate in the SIG as well.

The traffic on a similarly niche group like import-sig is only
intermittent, but it means that by the time we bring suggestions to
python-ideas or python-dev, we've already thrashed out the low level
arcana and know that whatever we're proposing *can* be made to work,
leaving the core lists to focus on the question of whether or not the
change *should* be made.

Whether or not to do that would be up to the folks with a specific
interest in working with dates and times, though.

Cheers,
Nick.



Would it be worth doing a straw poll to gauge how many people really 
need this, from my perspective anyway, level of complexity?  I've used 
datetimes a lot, but I don't even need naive timezones, completely dumb 
suits me.


Alternatively just go ahead, knowing that if the proposal isn't accepted 
into the stdlib it can at least go on pypi.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Chris Angelico]

On Tue, Jul 28, 2015 at 12:57 AM, Ronald Oussoren
 wrote:
> IMHO “+ 1 days” and “+ 24 hours” are two different things.  Date
> arithmetic is full of messy things like that.  “+ 1 month” is another
> example of that (which the datetime module punts completely
> and can be a source of endless bikeshidding).

https://www.youtube.com/watch?v=ppfpa5XgZHI

MATLAB defines "+ 1 month" as, if I'm not mistaken, "add the time it
would take to go from the beginning of time to the beginning of
January of the year 0 (which is totally a thing, by the way)". I'm
fairly sure that this is the most WAT-worthy definition possible, as
it means that adding one month does nothing, and adding two months
adds the length of January (31 days)... and adding three months adds
January + February, *in a leap year*.

But I agree that adding days and adding hours are different things. If
I add one day, I expect that the time portion should not change, in
the given timezone. (With the exception that DST switches might mean
that that time doesn't exist.) If I add 86400 seconds, I expect that
it should add 86400 ISO seconds to the time period, which might not be
the same thing. If you convert a datetime to a different timezone, add
86400 seconds, and convert back to the original timezone, I would
expect the result to be the same as adding 86400 seconds to the
original, unless there's something seriously bizarre going on with the
size of the second. But if you convert, add 1 day, and convert back,
you will get a different result if the two differ on DST. Does that
sound plausible?

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Sven R. Kunze]

I agree and my 2 cents: I can expect something different depending on 
the timezone and DST if I add


years
months
weeks
days
hours
minutes
seconds

to a given datetime

Even though, in 90% of the cases, there is a more or less obvious 
conversion formula between all of them. But consider months to days. 
That is not clear at all.


On 27.07.2015 19:11, Chris Angelico wrote:

On Tue, Jul 28, 2015 at 12:57 AM, Ronald Oussoren
 wrote:

IMHO “+ 1 days” and “+ 24 hours” are two different things.  Date
arithmetic is full of messy things like that.  “+ 1 month” is another
example of that (which the datetime module punts completely
and can be a source of endless bikeshidding).

https://www.youtube.com/watch?v=ppfpa5XgZHI

MATLAB defines "+ 1 month" as, if I'm not mistaken, "add the time it
would take to go from the beginning of time to the beginning of
January of the year 0 (which is totally a thing, by the way)". I'm
fairly sure that this is the most WAT-worthy definition possible, as
it means that adding one month does nothing, and adding two months
adds the length of January (31 days)... and adding three months adds
January + February, *in a leap year*.

But I agree that adding days and adding hours are different things. If
I add one day, I expect that the time portion should not change, in
the given timezone. (With the exception that DST switches might mean
that that time doesn't exist.) If I add 86400 seconds, I expect that
it should add 86400 ISO seconds to the time period, which might not be
the same thing. If you convert a datetime to a different timezone, add
86400 seconds, and convert back to the original timezone, I would
expect the result to be the same as adding 86400 seconds to the
original, unless there's something seriously bizarre going on with the
size of the second. But if you convert, add 1 day, and convert back,
you will get a different result if the two differ on DST. Does that
sound plausible?

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/srkunze%40mail.de


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Terry Reedy]

On 7/27/2015 11:21 AM, MRAB wrote:


Also, if you "add one year" to 29 February 2016, what date do you get?


I believe the 'conventional' answer is 1 March 2017.  That is also 1 Mar 
2016 + 1 year.  1 March 2017 - 1 year would be 1 Mar 2016.  Leap days 
get cheated.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

[Ronald Oussoren ]
> IMHO “+ 1 days” and “+ 24 hours” are two different things.
> Date arithmetic is full of messy things like that.

But it's a fact that they _are_ the same in naive time, which Python's
datetime single-timezone arithmetic implements:

- A minute is exactly 60 seconds.
- An hour is exactly 60 minutes.
- A day is exactly 24 hours.
- A week is exactly 7 days.

No context is necessary:  those are always true in naive time, and
that lack of mess is "a feature" to those who accept it for what it
is.

> “+ 1 month” is another example of that (which the datetime
> module punts completely and can be a source of endless
> bikeshidding).

Note that the only units timedelta accepts have clear (utterly
inarguable) meanings in naive time.  That's intentional too.  For
example, "a month" and "a year" have no clear meanings (as durations)
in naive time, so timedelta doesn't even pretend to support them.
Despite all appearance to the contrary in this thread, naive time is
bikeshed-free:  it's easy for someone to know all there is to know
about it by the time they're 12 ;-)

datetime + timedelta(days=1)

is equivalent to

datetime + timedelta(hours=24)

is equivalent to

datetime + timedelta(minutes=60*24)

is equivalent to

datetime + timedelta(seconds=60*60*24)

is equivalent to

datetime + timedelta(microseconds=100*60*60*24)

Naive time is easy to understand, reason about, and work with.  When
it comes to the real world, political adjustments to and within time
zones can make the results dodgy, typically in the two DST-transition
hours per year when most people living in a given time zone are
sleeping.  How much complexity do you want to endure in case they wake
up? ;-)  Guido's answer was "none in arithmetic - push all the
complexity into conversions - then most uses can blissfully ignore the
complexities".

And note that because DST transitions "cancel out" over the span of a
year, the benefits and the few dodgy cases don't really change
regardless of whether you add one week or a hundred thousand weeks
(although there's no way to predict what governments will decide the
local clock "should say" a hundred thousand weeks from now - it's only
predictable in naive time).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Terry Reedy]

On 7/27/2015 3:09 AM, Tim Peters wrote:

[Paul Moore ]


As an example, consider an alarm clock. I want it to go off at 7am
each morning. I'd feel completely justified in writing
tomorrows_alarm = todays_alarm + timedelta(days=1).


[Lennart Regebro ]

That's a calendar operation made with a timedelta.


It's an instance of single-timezone datetime arithmetic, of the
datetime + timedelta form.  Your examples have been of the same form.
Note that after Paul's

  tomorrows_alarm = todays_alarm + timedelta(days=1)

it's guaranteed that

 assert tomorrows_alarm - todays_alarm == timedelta(days=1)

will succeed too.


The "days" attribute here is indeed confusing as it doesn't mean 1 day,
it means 24 hours.


Which, in naive arithmetic, are exactly the same thing.


I think using the word 'naive' is both inaccurate and a mistake.  The 
issue is civil or legal time versus STEM time, where the latter includes 
applications like baking cakes.  It could also be called calendar time 
versus elapsed time.  (Financial/legal arithmetic versus STEM arithmetic 
is a somewhat similar contrast.)


The idea that an hour can be sliced out of a somewhat random March day 
and inserting it into a somewhat random October day is rather 
sophisticated.  It came from the minds of government bureaucrats.  It 
might be smart, dumb, or just a cunning way for civil authorities to 
show who is in charge by making us all jump.  But not 'naive'.


'Naive' means simple, primitive, or deficient in informed judgement. It 
is easy to take it as connoting 'wrong'.  Tim, you have been arguing 
that civil/legal time arithmetic is not naive. Calling civil time naive 
undercuts this claim.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Building python 2.7.10 for Windows from source

[Terry Reedy]

On 7/27/2015 10:25 AM, Mark Kelley wrote:

Thanks, that got me a bit further.  Now I'm wondering how I figure out
which version of tcl,tk and Tix actually got built with the 2.7.10
installer.


This is really a python-list question, but for the PSF installer, 
tcl/tk 8.5.15


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Chris Angelico]

On Tue, Jul 28, 2015 at 4:49 AM, Tim Peters  wrote:
> But it's a fact that they _are_ the same in naive time, which Python's
> datetime single-timezone arithmetic implements:
>
> - A minute is exactly 60 seconds.

No leap second support, presumably. Also feature?

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

>>> The "days" attribute here is indeed confusing as it doesn't mean 1 day,
>>> it means 24 hours.

>> Which, in naive arithmetic, are exactly the same thing.

[Terry Reedy]
> I think using the word 'naive' is both inaccurate and a mistake.  The issue
> is civil or legal time versus STEM time, where the latter includes
> applications like baking cakes.

Sorry, never heard of "STEM time" before - & a quick Google search didn't help.

> It could also be called calendar time versus elapsed time.  (Financial/legal
> arithmetic versus STEM arithmetic is a somewhat similar contrast.)

And I am, alas, equally unclear on what any of those others mean
(exactly) to you.

> The idea that an hour can be sliced out of a somewhat random March day and
> inserting it into a somewhat random October day is rather sophisticated.  It
> came from the minds of government bureaucrats.  It might be smart, dumb, or
> just a cunning way for civil authorities to show who is in charge by making
> us all jump.  But not 'naive'.

I agree.  Python's "naive time" single-timezone arithmetic
intentionally ignores all that:  it ignores leap seconds, it ignores
DST transition points, it ignores governments deciding to change the
base UTC offset within a pre-existing time zone, ...  It's time s
naive that it thinks 24 hours is the same thing as a day ;-)

> 'Naive' means simple, primitive, or deficient in informed judgement. It is
> easy to take it as connoting 'wrong'.

While some people in this thread seem convinced Python's naive time
_is_ "wrong", it's not because it's called "naive".  In any case,
Guido decided to call it "naive" over 13 years ago, starting here, and
that terminology has been in use ever since:

https://mail.python.org/pipermail/python-dev/2002-March/020648.html

> Tim, you have been arguing that civil/legal time arithmetic is not naive.

Yes.  But that's not "an argument", it's a plain fact that Python's
"naive time" (note that "naive" here is technical term, used widely in
the datetime docs) is not civil/legal time (assuming I understand what
you mean by that phrase).

> Calling civil time naive undercuts this claim.

I don't see that I ever said civil time is naive.  Adding a day is
_not_ always the same as adding 24 hours in (at least Lennart's
beliefs about) civil time.  They _are_ always the same in Python's
("naive") datetime arithmetic.  And the latter is all I said in the
quote at the top of this msg.

What am I missing?  It's always something ;-)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Chris Barker]

On Mon, Jul 27, 2015 at 11:55 AM, Terry Reedy  wrote:

> I think using the word 'naive' is both inaccurate and a mistake.
>


> 'Naive' means simple, primitive, or deficient in informed judgement. It is
> easy to take it as connoting 'wrong'.


In this context "naive" means "having no knowledge of timezone". And it
does make some sense as a word to use in that case. I don't like it much,
but it's the term used in the datetime module docs, so there you go.

and infact, everything Tim said can also apply to UTC time. We've had a lot
of discussion on teh numpy list about the difference between UTC and
"naive" times, but for practicle putrposes, they are exactly the same --
unitl you try to convert to a known time zone anyway.

But really, the points Tim was making are not about timezones at all -- but
about two concepts:

Time arithmetic with:
 1) Time spans (timedeltas) -- this is an "amount" of time, and can be
added, subtracted, etc to a datetime. such time spans have various
appropriate units, like seconds, days. weeks -- but, as Tim pointed out,
"years" is NOT an appropriate unit of timedeltas, and should not be allowed
in any lib that uses them.

2) Calendar time arithmetic: this is things like "next year", "next week",
"two years from now" -- these are quite tricky, and in some special cases
have no obvious clear definition (leap years, etc...).

Calendar manipulations like (2) should be kept completely separate from
time span manipulation. Is anyone suggesting adding that to the standard
lib?

-Chris


-- 

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.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Chris Barker]

On Mon, Jul 27, 2015 at 12:07 PM, Chris Angelico  wrote:

> > - A minute is exactly 60 seconds.
>
> No leap second support, presumably. Also feature?
>

Leap seconds come in when you convert to a Calendar representation -- a
minute is 60 seconds, always -- even when passing over a leap second.

-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.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

[Tim]
>> But it's a fact that they _are_ the same in naive time, which Python's
>> datetime single-timezone arithmetic implements:
>>
>> - A minute is exactly 60 seconds.
>> ...

[Chris Angelico ]
> No leap second support, presumably. Also feature?

Absolutely none, and absolutely "a feature", but that didn't start
with the datetime module.  Read Guido's original 13+ year old message
about "naive time":

https://mail.python.org/pipermail/python-dev/2002-March/020648.html

Note especially this part:

"""
I'm thinking that for most *business* uses of date and time, we should
have the same attitude towards DST that we've already decided to take
towards leap seconds.
"""

Guido has never had the slightest use for leap seconds in any part of
Python's implementation, and has consistently opposed attempts to
incorporate them.  This was well established long before datetime was
even an idea.

Here's another, later quote from him:

"""
Python's datetime objects will not support leap seconds in any way,
shape or form.  A tzinfo object that does support leap seconds is on
its own, but I don't see the point since Python will never represent a
time as a number of seconds since some epoch.  (If you want to get a
POSIX time_t value, you'll have to convert first to local time, then
to a struct tm, and then use mktime().)
"""
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Terry Reedy]

On 7/27/2015 3:14 PM, Tim Peters wrote:


[Terry Reedy]

I think using the word 'naive' is both inaccurate and a mistake.  The issue
is civil or legal time versus STEM time, where the latter includes
applications like baking cakes.


Sorry, never heard of "STEM time" before - & a quick Google search didn't help.


Searching for 'STEM' to discover the meaning of the acronym displays, 
for me, after the second
"STEM is an acronym referring to the academic disciplines of science, 
technology, engineering and mathematics." STEM time is the time used in 
science, technology, engineering and mathematics, with the added note 
indicating that I mean for technology and engineering to be taken 
broadly, to include all uses of actual (natural) elapsed time, as 
opposed to occasionally artificial government time.



The idea that an hour can be sliced out of a somewhat random March day and
inserting it into a somewhat random October day is rather sophisticated.  It
came from the minds of government bureaucrats.  It might be smart, dumb, or
just a cunning way for civil authorities to show who is in charge by making
us all jump.  But not 'naive'.


I agree.  Python's "naive time" single-timezone arithmetic
intentionally ignores all that:  it ignores leap seconds, it ignores
DST transition points, it ignores governments deciding to change the
base UTC offset within a pre-existing time zone, ...  It's time s
naive that it thinks 24 hours is the same thing as a day ;-)


To me, having 1 day be 23 or 25 hours of elapsed time on the DST 
transition days, as in Paul's alarm example, hardly ignores the 
transition point.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

[Chris Barker]
> ...
> and infact, everything Tim said can also apply to UTC time. We've had a lot
> of discussion on teh numpy list about the difference between UTC and "naive"
> times, but for practicle putrposes, they are exactly the same -- unitl you
> try to convert to a known time zone anyway.

Yes, "naive arithmetic" is "correct" (by everyone's definition) in any
time zone that has a fixed-for-all-eternity offset from UTC.  UTC is
the simplest case of that (with offset 0).

So for all practical purposes you can think of a naive datetime as
being "the time" in any eternally-fixed-offset time zone you like - or
as in no time zone at all (the time zone _concept_ isn't necessary to
grasp naive time - it only takes effort to _forget_ it).  But the
paranoid should consider that nothing can stop governments from
changing the definition of UTC (or any other time zone).  They'll have
to pry your naive datetimes out of your computer's cold, dead disk
drives though ;-)


> ...
> 2) Calendar time arithmetic: this is things like "next year", "next week",
> "two years from now" -- these are quite tricky, and in some special cases
> have no obvious clear definition (leap years, etc...).
>
> Calendar manipulations like (2) should be kept completely separate from time
> span manipulation. Is anyone suggesting adding that to the standard lib?

It comes up, and would be useful to many.  But it's the kind of thing
waiting for an extension module to take the world by storm.  If people
think the bikeshedding in _this_ thread is excessive ... ;-)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

[Terry Reedy ]
> To me, having 1 day be 23 or 25 hours of elapsed time on the DST transition
> days, as in Paul's alarm example, hardly ignores the transition point.

It's 2:56PM.  What time will it be 24 hours from now?  If your answer
is "not enough information to say, but it will be some minute between
1.56PM and 3:56PM inclusive", you want to call _that_ "naive"?  I sure
don't.  You can only give such an answer if you're acutely aware of
(for example) DST transitions.

If you're truly naive, utterly unaware of the possibility of
occasional time zone adjustments, then you give the obvious answer:
2:56PM.  That's what Python's datetime arithmetic gives.  That's naive
in both technical and colloquial senses.

You're only aware of that "2:56PM tomorrow" may be anywhere between 23
and 25 hours away from "2:56PM today" because you're _not_ ignoring
possible transitions.  So,. sure, I agree that your pointing it out
"hardly ignores the transition point".  But I wasn't talking about you
;-)  I was talking about the arithmetic, which does thoroughly ignore
it.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Ethan Furman]

On 07/27/2015 07:46 AM, Lennart Regebro wrote:

On Mon, Jul 27, 2015 at 4:13 PM, Steven D'Aprano wrote:


To me, Paul's example is a datetime operation: you start with a datetime
(7am today), perform arithmetic on it by adding a period of time (one
day), and get a datetime as the result (7am tomorrow).


Well, OK, let's propose these wordings: It looks like a date
operation, ie, add one to the date, but in reality it's a time
operation, ie add 86400 seconds to the time. These things sound
similar but are very different.


I have to disagree.  If I have my alarm at 7am (localtime ;) so I can be at 
work at 8am I don't care exactly how many seconds have passed, that alarm 
better go off at 7am local time.

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

[Tim]
>> Python didn't implement timezone-aware arithmetic at all within a
>> single time zone.  Read what I wrote just above.  It implements naive
>> arithmetic within a single time zone.

[Jon Ribbens ]
> This usage of "time zone" is confusing.

Ha!  _All_ usages of "time zone" are confusing ;-)

This specific use pointed at something pretty trivial to state but
technical:  any instance of Python datetime arithmetic in which the
datetime input(s) and, possibly also the output, share the same tzinfo
member(s).  Specifically:

 datetime + timedelta
 datetime - timedelta
 datetime - datetime

Maybe another, but you get the idea.  Those all do "naive datetime
arithmetic", and in the last case the "same tzinfo member" part is
crucial (if the input datetimes have different tzinfo members in
subtraction, we're no longer "within a single time zone", and time
zone adjustments _are_ made:  it acts like both inputs are converted
to UTC before subtracting; but not so if both inputs share their
tzinfo members).

> As far as I can tell, you really mean "UTC offset". A time zone
> would be something like "Europe/London", which has two different
> UTC offsets throughout the year (not to mention other historical
> weirdnesses), whereas arithmetic on a "timezone-aware" datetime
>: is only going to work so long as you don't cross any of the
> boundaries where the UTC offset changes.

In this context I only had in mind tzinfo members.  They may represent
fixed-offset or multiple-offset "time zones" (or anything else a
programmer dreams up), or may even be None.  The datetime
implementation has no idea what they represent:  the implementation
can only judge whether two given tzinfo objects are or aren't the same
object.  So "within a single time zone" here just means there's only
one tzinfo object in play.

> I agree with you about pretty much everything else about datetime,
> just I find the terminology misleading. The only other thing I found
> really weird about datetime is how Python 2 had no implementation of
> a UTC tzinfo class, despite this being utterly trivial - but it's too
> late to do anything about that now, of course.

At the time, Guido ran his time machine forward, and saw that Stuart
Bishop would soon enough supply all the time zones known to mankind
;-)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

On Mon, Jul 27, 2015 at 9:47 PM, Ethan Furman  wrote:
> On 07/27/2015 07:46 AM, Lennart Regebro wrote:
>> Well, OK, let's propose these wordings: It looks like a date
>> operation, ie, add one to the date, but in reality it's a time
>> operation, ie add 86400 seconds to the time. These things sound
>> similar but are very different.
>
> I have to disagree.  If I have my alarm at 7am (localtime ;) so I can be at
> work at 8am I don't care exactly how many seconds have passed, that alarm
> better go off at 7am local time.

Right. And then adding 86400 seconds to it is not the right thing to do.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Brett Cannon]

On Mon, Jul 27, 2015 at 7:49 AM Lennart Regebro  wrote:

> On Mon, Jul 27, 2015 at 4:45 PM, Nick Coghlan  wrote:
> > On 28 July 2015 at 00:27, Steve Dower  wrote:
> >> Am I the only one feeling like this entire thread should be moved to
> >> python-ideas at this point?
> >
> > Since this is an area where the discussion of implementation details
> > and the discussion of the developer experience can easily end up at
> > cross purposes, I'm wondering if there may be value in actually
> > splitting those two discussions into different venues by creating a
> > datetime-sig, and specifically inviting the pytz and dateutil
> > developers to participate in the SIG as well.
>
> +1 for that.
>

Alexander and Tim, you okay with moving this conversation to a datetime-sig
if we got one created?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

[Paul Moore]
> ...
> I think the following statements are true. If they aren't, I'd
> appreciate clarification. I'm going to completely ignore leap seconds
> in the following - I hope that's OK, I don't understand leap seconds
> *at all* and I don't work in any application areas where they are
> relevant (to my knowledge) so I feel that for my situation, ignoring
> them (and being able to) is reasonable.

Guido will never allow any aspect of "leap seconds" into the core,
although it's fine by him if someone wants to write their own tzinfo
class to try to model them.


> Note that I'm not talking about internal representations - this is
> purely about user-visible semantics.
>
> 1. "Naive" datetime arithmetic means treating a day as 24 hours, an
> hour as 60 minutes, etc. Basically base-24/60/60 arithmetic.

It also means that the tzinfo(s) member (if any) is(are) ignored.  So
not only leap seconds are ignored:

1. Possible DST transitions are ignored.
2. Possible changes to the base UTC offset are ignored.
3. Possible changes to the name of the time zone (even if "the rules"
don't change) are ignored.
4. Everything else whatsover that could be learned from the tzinfo
member is ignored.

Note that in "aware" arithmetic, the current fromutc() implementation
is only strong enough to account reliably for #1.

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

> 3. Converting between (fixed offset) timezones is a separate issue
> from calculation - but it's nothing more than applying the relevant
> offsets.

Yup!  Although that can't be exploited by Python:  there's nothing in
a tzinfo instance Python can query to discover the rules it
implements.

> 4. Calculations involving 2 different timezones (fixed-offset ones as
> above) is like any other exercise involving values on different
> scales. Convert both values to a common scale (in this case, a common
> timezone) and do the calculation there. Simple enough.

Yup.

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

> 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).  Everyone ignores #4, and always will ;-)

> (I'm not sure that the original implementation included fixed-offset tzinfo
> objects, but the 3.4 docs say they are there now, so that's fine).

The original implementation supplied no tzinfo objects, only an
abstract tzinfo base class.

> Looking at the complicated cases, the only ones I'm actually aware of
> in practice are the ones that switch to DST and back, so typically
> have two offsets that differ by an hour,

Some number of minutes, anyway (not all DST transitions move by whole hours).

> switching between the two at some essentially arbitrary points. If there are
> other more complex forms of timezone, I'd like to never need to know about
> them, please ;-)

#2 above is common enough, although there's not a _lot_ of
base-offset-changing going on in current times.

> The timezones we're talking about here are things like
> "Europe/London", not "GMT" or "BST" (the latter two are fixed-offset).
>
> There are two independent issues with complex timezones:
>
> 1. Converting to and from them. That's messy because the conversion to
> UTC needs more information than just the date & time (typically, for
> example, there is a day when 01:45:00 maps to 2 distinct UTC times).
> This is basically the "is_dst" bit that Tim discussed in an earlier
> post. The semantic issue here is that users typically say "01:45" and
> it never occurs to them to even think about *which* 01:45 they mean.
> So recovering that extra information is hard (it's like dealing with
> byte streams where the user didn't provide details of the text
> encoding used).

"Flatly impossible" is more on target than "hard".  In the case of
text encoding, it's often possible to guess correctly by statistical
analysis of the bytes.  01:45:00 in isolation gives no clue at all
about whether standard or daylight time was intended.  A similar point
applies to some ambiguous cases when the base ("standard") UTC offset
changes.

> Once we have the extra information, though, doing
> conversions is just a matter of applying a set of rules.

Yup, and it's easy.

> 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.
> So you have 2 mutually incompatible semantic 

Re: [Python-Dev] Status on PEP-431 Timezones

[Ethan Furman]

On 07/27/2015 01:42 PM, Lennart Regebro wrote:

On Mon, Jul 27, 2015 at 9:47 PM, Ethan Furman wrote:

On 07/27/2015 07:46 AM, Lennart Regebro wrote:



Well, OK, let's propose these wordings: It looks like a date
operation, ie, add one to the date, but in reality it's a time
operation, ie add 86400 seconds to the time. These things sound
similar but are very different.


I have to disagree.  If I have my alarm at 7am (localtime ;) so I can be at
work at 8am I don't care exactly how many seconds have passed, that alarm
better go off at 7am local time.


Right. And then adding 86400 seconds to it is not the right thing to do.


Yes, it is, because that's the number that will get me to 7am the next day.  My 
program has no control over the computer's clock -- it merely works with what 
it is told by the computer's clock.

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

[Brett Cannon ]
\> Alexander and Tim, you okay with moving this conversation to a datetime-sig
> if we got one created?

Fine by me!
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Paul Moore]

On 27 July 2015 at 22:10, Tim Peters  wrote:
>> 1. Converting to and from them. That's messy because the conversion to
>> UTC needs more information than just the date & time (typically, for
>> example, there is a day when 01:45:00 maps to 2 distinct UTC times).
>> This is basically the "is_dst" bit that Tim discussed in an earlier
>> post. The semantic issue here is that users typically say "01:45" and
>> it never occurs to them to even think about *which* 01:45 they mean.
>> So recovering that extra information is hard (it's like dealing with
>> byte streams where the user didn't provide details of the text
>> encoding used).
>
> "Flatly impossible" is more on target than "hard".  In the case of
> text encoding, it's often possible to guess correctly by statistical
> analysis of the bytes.  01:45:00 in isolation gives no clue at all
> about whether standard or daylight time was intended.  A similar point
> applies to some ambiguous cases when the base ("standard") UTC offset
> changes.

By "hard", what I meant was that you'd have to explain what you need
to the user, and accept their answer, in the user interface to your
application. Explaining why you need to know in a way that isn't
totally confusing is what I classed as "hard".

I wouldn't even consider trying to guess the user's intent. Although
"if you don't say, I'll use naive datetimes" seems to me a plausible
position to take if you want to allow the user not to care. Strange
that this is how Python works... ;-)

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Ethan Furman]

To use Alexander's example:


--> t = datetime(2015, 3, 7, 12, tzinfo=timezone('US/Eastern'))
--> t.strftime('%D %T %z %Z')
'03/07/15 12:00:00 -0500 EST'

--> (t + timedelta(1)).strftime('%D %T %z %Z')
'03/08/15 12:00:00 -0400 EDT'


The data (aka the time) should act naively, but the metadata (aka the timezone) 
is what should be changing [1].

--
~Ethan~

[1] Which is to say that naive datetime's should continue as-is, and aware 
datetimes should exhibit the above behavior.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/27/2015 02:04 AM, Tim Peters wrote:
> The naive arithmetic within a timezone is already correct, by its own 
> internal criteria.  It's also useful (see the original discussions,
> or Paul Moore's recent brief account).

"Naive" alarm clocks (those which don't know from timezones) break human
expectations twice a year, because their users have to be awake to fix
them (or make the clock itself out-of-whack with real civil time for the
hours between fixing and the actual transition). For confirmatoin, ask
your local priest / pastor about the twice yearly mixups among
congregants whose clocks don't self-adjust for the DST boundary:  some
show up late / early for church *every* time the local zone changes.

I'd be in favor of dropping "days" from timedelta, myself, for just this
reason:  if "1 day" is the same for your usecase as "24 hours", then just
do the math yourself.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJVtqPcAAoJEPKpaDSJE9HY4oEP+wUSWTeQS7cn3FLVBOeUV/lZ
MIqZSnIGYOaSS6JDo2oTjm+yQWySEp5QMXHNYohPOkkkYDdu8L/r250KKb6F3fbo
OMnNXlBCVHi66kFCs0x3+zQIlhSzkYV2FcT39gNu0llw5gODtmbbvYZE+CA4ej6R
PIhnizyT7bXa+q2WYBrL0/+w/IBuv4H3d/x0b79cPZpqRZeI57k90qsee9SSPyDb
MGs76IUOfJuZNruqfuY+zhFlfwB5kOt8U4kTlXZS4At1TKskoH5zuIiaHZooN6gy
fBz3Zzt2XKYiWPWrzEbVeXrdXmAFRyr5sWqVQ0SliKA06rq1Tr5h53orGLidMaPe
noUnz8YQHssY5e/kAbSUv6C93GNbldNEFOV1Ab03JT+NPrhNxPqi1ZGTJsMDc+Tl
HI2I5C1TXW8ZPx/US2+Zt0yu0HX82EX03UPlRW4wZZSyKw7eCosF9fWXwufF9yTP
9v0otEB/x3rN1TJgc+7U4r1JmYPy+eYyjKs1xy58kb/a7awSvlmEeWvQelGqQKc+
lnRT6VxzVlgmTginq/5oHyFkI5OFTYuukuQDZx3ocd1g7EX42pNRYHVcMbZiQ9L5
DFKrENQDkegTkX+g1BUlVSW67smrFfki6Y7O/5R378x+q/sn6oqYe9334C+ccbz8
8jA16niF9EiwaxieLH9w
=I31e
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

[Tres Seaver ]
> "Naive" alarm clocks (those which don't know from timezones) break human
> expectations twice a year, because their users have to be awake to fix
> them (or make the clock itself out-of-whack with real civil time for the
> hours between fixing and the actual transition). For confirmatoin, ask
> your local priest / pastor about the twice yearly mixups among
> congregants whose clocks don't self-adjust for the DST boundary:  some
> show up late / early for church *every* time the local zone changes.

Sure.  I don't see how this applies to Python's arithmetic, though.
For a start, you're talking about alarm clocks ;-)  Note that "naive"
is a technical term in the datetime context, used all over the
datetime docs.  However, I'm using "naive arithmetic" as a shorthand
for what would otherwise be a wall of text.  That's my own usage; the
docs only apply "naive" and "aware" to date, time and datetime objects
(not to operations on such objects).


> I'd be in favor of dropping "days" from timedelta, myself, for just this
> reason:  if "1 day" is the same for your usecase as "24 hours", then just
> do the math yourself.

timedelta objects only store days, seconds, and microseconds, which is
advertised.  It would be bizarre not to allow to set them directly.
They're the only timedelta components for which instance attributes
exist.  In the timedelta constructor, it's the seconds,  milliseconds,
minutes, hours, and weeks arguments that exist solely for convenience.
You could "do the math yourself" for all those too - but why would you
want to make anyone do that for any of them?  All the world's alarm
clocks would remain just as broken regardless ;-)

Even if days weren't a distinguished unit for timedelta, I'd still
much rather write, e.g.,

timedelta(days=5, hours=3)

than

timedelta(hours=123)

or

timedelta(hours=5*24 + 3)

etc.  The intent of the first spelling is obvious at a glance.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Ronald Oussoren]

> On 27 jul. 2015, at 20:49, Tim Peters  wrote:
> 
> [Ronald Oussoren ]
>> IMHO “+ 1 days” and “+ 24 hours” are two different things.
>> Date arithmetic is full of messy things like that.
> 
> But it's a fact that they _are_ the same in naive time, which Python's
> datetime single-timezone arithmetic implements:
> 
> ...
> 
> Naive time is easy to understand, reason about, and work with.  When
> it comes to the real world, political adjustments to and within time
> zones can make the results dodgy, typically in the two DST-transition
> hours per year when most people living in a given time zone are
> sleeping.  How much complexity do you want to endure in case they wake
> up? ;-)  Guido's answer was "none in arithmetic - push all the
> complexity into conversions - then most uses can blissfully ignore the
> complexities".

I totally agree with that, having worked on applications that had to deal with 
time a lot and including some where the end of a day was at 4am the following 
day.  That app never had to deal with DST because not only are the transitions 
at night, the are also during the weekend. 


Treating time as UTC with conversions at the application edge might be 
"cleaner" in some sense, but can make code harder to read for application 
domain experts.

It might be nice to have time zone aware datetime objects with the right(TM) 
semantics, but those can and should not replace the naive objects we know and 
love. 

That said,  I have had the need for date delta objects that can deal with 
deltas expressed at days or months but it is easy enough to write your own 
library for that that can deal with the local conventions for those. 

Ronald
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Mon, Jul 27, 2015 at 5:13 PM, Tim Peters  wrote:

> [Brett Cannon ]
> \> Alexander and Tim, you okay with moving this conversation to a
> datetime-sig
> > if we got one created?
>
> Fine by me!
>

+1

Didn't  datetime-sig exist some 12 years ago?  It would be nice to get some
continuity from that effort.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[ISAAC J SCHWABACHER]

Responses to several partial messages follow.

[Lennart Regebro]
> Then we can't implement timezones in a reasonable way with the current
> API, but have to have something like pytz's normalize() function or
> similar.
>
> I'm sorry I've wasted everyones time with this PEP.

[ijs]
I think that integrating pytz into the stdlib, which is what the PEP proposes, 
would be valuable even without changing datetime arithmetic. But I see ways to 
accomplish the latter without breaking backward compatibility. The dream ain't 
dead! See below.

[Paul Moore]
> 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.
> 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.

> It seems to me that the problem is that for this latter issue, it's
> the *timedelta* object that's not rich enough.

[ijs]
Yes! This is the heart of the matter. We can solve *almost* all the problems by 
having multiple competing timedelta classes-- which we already have. Do you 
care about what will happen after a fixed amount of elapsed time? Use 
`numpy.timedelta64` or `pandas.Timedelta`. Want this time tomorrow, come hell, 
high water, or DST transition? Use `dateutil.relativedelta.relativedelta` or 
`mx.DateTime.RelativeDateTime`. As long as the timedelta objects we're using 
are rich enough, we can make `dt + delta` say what we mean. There's no reason 
we can't have both naive and aware arithmetic in the stdlib at once.

All the stdlib needs is an added timedelta class that represents elapsed atomic 
clock time, and voila!

The biggest problem that this can't solve is subtraction. Which timedelta type 
do you get by subtracting two datetimes? Sure, you can have a 
`datetime.elapsed_since(self, other: datetime, **kwargs) -> 
some_timedelta_type` that determines what you want from the kwargs, but 
`datetime.__sub__` doesn't have that luxury. I think the right answer is that 
subtraction should yield the elapsed atomic clock time, but that would be a 
backward-incompatible change so I don't put a high probability on it happening 
any time soon. See the last message (below) for more on this.

> You can't say "add 1
> day, and by 1 day I mean keep the same time tomorrow" as opposed to
> "add 1 day, and by that I mean 24 hours"[1]. In some ways, it's
> actually no different from the issue of adding 1 month to a date
> (which is equally ill-defined, but people "know what they mean" to
> just as great an extent). Python bypasses the latter by not having a
> timedelta for "a month". C (and the time module) bypasses the former
> by limiting all time offsets to numbers of seconds - datetime gave us
> a richer timedelta object and hence has extra problems.

Because of the limits on the values of its members, `datetime.timedelta` is 
effectively just a counter of microseconds. It can't distinguish between 1 day, 
24 hours, 1440 minutes or 86400 seconds. They're all normalized to the same 
value. So it's not actually richer; it only appears so.

> I don't have any solutions to this final issue. But hopefully the
> above analysis (assuming it's accurate!) helps clarify what the actual
> debate is about, for those bystanders like me who are interested in
> following the discussion. With luck, maybe it also gives the experts
> an alternative perspective from which to think about the problem - who
> knows?
>
> Paul
>
> [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. Is that what Lennart has been trying to
> say in his posts?

I thought for a long time that this would be sufficient, and I still think it's 
a good spelling that makes it clear what the user wants most of the time, but I 
have wanted things like "the first time the clock shows 1 hour later than it 
shows right now" enough times that I no longer think this is quite sufficient. 
(I *think* you can do that with `dt + 
dateutil.relativedelta.relativedelta(hour=dt.hour+1, minute=0, second=0, 
microsecond=0)`, but I'm not sure.)

[Tim Peters]
> Ah, but it already happens that way - because the builtin datetime
> arithmetic is "naive".  The docs have always promised this:
>
> """
> datetime2 = datetime1 + timedelta (1)
> datetime2 = datetime1 - timedelta (2)
>
> 1) datetime2 is a duration of timedelta removed from datetime1, moving
> forward in time if timedelta.days > 0, or backward if timedelta.days <
> 0. The result has the same tzinfo at

Re: [Python-Dev] Status on PEP-431 Timezones

[Glenn Linderman]

On 7/27/2015 1:42 PM, Lennart Regebro wrote:

On Mon, Jul 27, 2015 at 9:47 PM, Ethan Furman  wrote:

On 07/27/2015 07:46 AM, Lennart Regebro wrote:

Well, OK, let's propose these wordings: It looks like a date
operation, ie, add one to the date, but in reality it's a time
operation, ie add 86400 seconds to the time. These things sound
similar but are very different.

I have to disagree.  If I have my alarm at 7am (localtime ;) so I can be at
work at 8am I don't care exactly how many seconds have passed, that alarm
better go off at 7am local time.

Right. And then adding 86400 seconds to it is not the right thing to do.


It is the right thing to do... but one also adds/subtracts 3600 seconds 
from it before going to bed 2 days a year, due to government 
interference, unless it is an atomic clock or cell-phone, which do those 
updates automatically.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Chris Barker]

On Mon, Jul 27, 2015 at 12:47 PM, Ethan Furman  wrote:

> To me, Paul's example is a datetime operation: you start with a datetime
>>> (7am today), perform arithmetic on it by adding a period of time (one
>>> day), and get a datetime as the result (7am tomorrow).
>>>
>>
>> Well, OK, let's propose these wordings: It looks like a date
>> operation, ie, add one to the date, but in reality it's a time
>> operation, ie add 86400 seconds to the time. These things sound
>> similar but are very different.
>>
>
> I have to disagree.  If I have my alarm at 7am (localtime ;) so I can be
> at work at 8am I don't care exactly how many seconds have passed, that
> alarm better go off at 7am local time.
>

sure, but that is very much a Calendar operation -- "7am tomorrow", On the
other hand, if you wanted to sleep a particular length of time,t hen you
might want your alarm to go off "in 8 hours" -- that is a different
operation.

Calendar operations are very, very useful, but not on the table in this
discussion, are they?

-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.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Chris Barker]

> The only other thing I found
> > really weird about datetime is how Python 2 had no implementation of
> > a UTC tzinfo class, despite this being utterly trivial -


Huh? it is either so trivial that there is no point -- simiply say that
your datetimes are UTC, and you are done.

Or it's not the least bit trivial -- the only difference between a UTC
datetime and a "naive" datetime is that one can be converted to (or
interact with) other time zones. Except that, as we know from this
conversation, is very, very non-trivial!

(Also, technically, UTC would use leap-seconds...)

-Chris

-- 

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.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Please create the datetime-sig mailing list

[Brett Cannon]

[bcc'ed python-dev]

Initial admin can be me and I will be in charge of finding more suitable
admins to manage the list.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Chris Barker]

On Mon, Jul 27, 2015 at 2:10 PM, Tim Peters  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.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archiv

Re: [Python-Dev] Status on PEP-431 Timezones

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/27/2015 06:03 PM, Tim Peters wrote:

> Even if days weren't a distinguished unit for timedelta, I'd still 
> much rather write, e.g.,
> 
> timedelta(days=5, hours=3)
> 
> than
> 
> timedelta(hours=123)
> 
> or
> 
> timedelta(hours=5*24 + 3)
> 
> etc.  The intent of the first spelling is obvious at a glance.

- From a human's perspective, "a day from now" is always potentially
unambigous, just like "a month from now" or "a year from now", whereas
"24 hours from now" is never so.  In a given application, a user who
doesn't care can always write a helper function to generate hours;  in an
applicatino whose developer who *does* care, the 'days' argument to
timedelta in its current does *not* help achieve her goal:  it is an
attractive nuisance she will have to learn to avoid.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJVttPGAAoJEPKpaDSJE9HY0N4QAMQ+Q1/m6Dgg97aS1fRFrMA1
gi7lrWEuW0II0V9bOvB+j0IkASBahreauYb+MBnXXSy1JEDRpVQX7h4SHzLMQ+TF
YSKnxCCY1UktpegkriZF7FoN8Rhv3egA01qWPO0RjHUkZym7/W2zN5cXhRTeij8N
dbAcoT5y4gdii55T+edWjYNJDFihgKNEuh2KMPmMH37tYqOKCFsz1ojX2ox7e4dC
2yEACVz8G+bmUQQ/WXRKsM4pvMf616U9qkMcEYCVzqV+4smX+/z6c7gs244UVcr4
b4m6Du6UTNAtZpSkToYZvN9R2WbDmbG4FnUrF9eso7m1S2BjdlNyxJS7zGmp+Ttj
XxmPeptC/INx8EaILYlB70gDDVztU+QBeolP9lfmfpY3srhI1a2uIGH2LhhOuy+F
xcRoGaOIg3+JFyPa8ye6OAg6Vka9h+e02ZWaAAxfRhZgnnNduUnTaomuTKi8sCAa
s3AHG4E5dOTJdLGxhgVEOSl9nqIJNmVxLxxb2utcS7W5G28KHYLzgV6w2r/fOkYf
FvN5Lj6qQuQTPKdN807/7cl1fqOGPg4P74GMojVA816aNtjh4hTw/2AXqZ0Q0LTq
QzhatRaDY+cu1SSZV9aDuCxvm4chjITucb6g7/dvR1xSY4Y+oxFgt3/KO2N5jJSY
jBlJGbgGp9kukkwO2ret
=Aw0Q
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/27/2015 06:11 PM, Ronald Oussoren wrote:

> Treating time as UTC with conversions at the application edge might
> be "cleaner" in some sense, but can make code harder to read for 
> application domain experts.
> 
> It might be nice to have time zone aware datetime objects with the 
> right(TM) semantics, but those can and should not replace the naive 
> objects we know and love.

Interesting.  My experience is exactly the opposite:  the datetimes which
"application domain experts" cared about *always* needed to be non-naive
(zone captured explicitly or from the user's machine and converted to
UTC/GMT for storage).  As with encoded bytes, allowing a naive instance
inside the borders the system was always a time-bomb bug (stuff would
blow up at a point far removed from which it was introduced).

The instances which could have safely been naive were all
logging-related, where the zone was implied by the system's timezone
(nearly always UTC).  I guess the difference is that I'm usually writing
apps whose users can't be presumed to be in any one timezone.  Even in
those cases, having the logged datetimes be incomparable to user-facing
ones would make them less useful.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJVttcdAAoJEPKpaDSJE9HYSlEP/0b7A9swT3m0uImdmzSZNJCW
EShQuxkclKlADP0Qqvshbiew1lsdqSPTZQ5QOUnqxeo+F0C1pCSABgFmXA3Jjzon
lxbwOGFFDhBburJ/F5zAO3XnawvL2p/M4dV+3Zea2inO0X+iNUuHvNjwx/e/qR4i
XdC8IyyJZtsFFL+l5KAv7xOT6SaCOB7OrVTZySHrhmfeziClzeBC8GWI00zYIQjj
BYQJB+lLhSBdb3b4u2fqhGtbrFtTHDDHEPC/mWdWAvzJN98YaeOtiTOAqiIg5Xai
TssJwAvonxOy5P8f5XdW03kbaKqmslWVk/0xIT7svjJnfPXVFzHoFJZZAJMEt34s
uZXu79g5ype8gyIJceXZV9/iS6GKHhfUlNTRvemJZb1aiq1QJ26otv2n97yqFbdo
PYfbjSU5EhK7h42138QYCM1JmKmIEIBbb+RN5O5ZaJqWEs1IstaMI1K7rM/Gt9dj
+Du0wV85Vi0ydgrZ2w8z2ZCL3bnl5wW7y8mBiSNWx1OEK7zRn/tq7/+nd9bFi1L0
8KIY8xJn5t0SU+5BSpisxTSAdX8JD6bAPy3wZlNDP8FFfB9zUyCrhRE58cDsvPdO
BQYteyWrpGQJxf2i5UQTLruW2JK3i1lL0en4spucQnBI/eHs7VVHMbfpOpdXhcIl
TR7c9fNwV0kn7EggTajx
=nRMI
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Mark Lawrence]

On 28/07/2015 01:58, Tres Seaver wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/27/2015 06:03 PM, Tim Peters wrote:


Even if days weren't a distinguished unit for timedelta, I'd still
much rather write, e.g.,

timedelta(days=5, hours=3)

than

timedelta(hours=123)

or

timedelta(hours=5*24 + 3)

etc.  The intent of the first spelling is obvious at a glance.


- From a human's perspective, "a day from now" is always potentially
unambigous, just like "a month from now" or "a year from now", whereas
"24 hours from now" is never so.  In a given application, a user who
doesn't care can always write a helper function to generate hours;  in an
applicatino whose developer who *does* care, the 'days' argument to
timedelta in its current does *not* help achieve her goal:  it is an
attractive nuisance she will have to learn to avoid.



To me a day is precisely 24 hours, no more, no less.  I have no interest 
in messing about with daylight savings of 30 minutes, one hour, two 
hours or any other variant that I've not heard about.


In my mission critical code, which I use to predict my cashflow, I use 
code such as.


timedelta(days=14)

Is somebody now going to tell me that this isn't actually two weeks?

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

[Ronald Oussoren]
>> Treating time as UTC with conversions at the application edge might
>> be "cleaner" in some sense, but can make code harder to read for
>> application domain experts.
>>
>> It might be nice to have time zone aware datetime objects with the
>> right(TM) semantics, but those can and should not replace the naive
>> objects we know and love.

[Tres Seaver ]
> Interesting.  My experience is exactly the opposite:  the datetimes which
> "application domain experts" cared about *always* needed to be non-naive
> (zone captured explicitly or from the user's machine and converted to
> UTC/GMT for storage).  As with encoded bytes, allowing a naive instance
> inside the borders the system was always a time-bomb bug (stuff would
> blow up at a point far removed from which it was introduced).

I strongly suspect that by "naive objects" here Ronald was really
talking about "naive _arithmetic_":  the current behavior where adding
24 hours (or 1 day - exactly the same thing for a timedelta) to an
aware datetime yields a new datetime with the same tzinfo member and
the same local time components, but where the day (and possibly month,
and possibly year) components have moved forward by a day (in the
plain English meaning of "a day").

That behavior has been discussed approximately infinitely often so far
in this thread, and was the overriding context in the message from
which Ronald's quote was pulled.

> The instances which could have safely been naive were all
> logging-related, where the zone was implied by the system's timezone
> (nearly always UTC).  I guess the difference is that I'm usually writing
> apps whose users can't be presumed to be in any one timezone.  Even in
> those cases, having the logged datetimes be incomparable to user-facing
> ones would make them less useful.

I bet the same is true for Ronald in some of his apps.

So what do _you_ do with datetime arithmetic, Tres?  Do you do
datetime calculations at all, or just store/retrieve values as-is?  If
the former, are you disturbed that adding timedelta(hours=24) to an
aware datetime object never changes the time components (only the day,
and possibly also month, and possibly also year)?  If that has
disturbed you, did you find a way to accomplish what you wanted
instead - or are you still stuck? ;-)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

[Mark Lawrence ]
> To me a day is precisely 24 hours, no more, no less.  I have no interest in
> messing about with daylight savings of 30 minutes, one hour, two hours or
> any other variant that I've not heard about.
>
> In my mission critical code, which I use to predict my cashflow, I use code
> such as.
>
> timedelta(days=14)
>
> Is somebody now going to tell me that this isn't actually two weeks?

Precisely define what "two weeks" means, and then someone can answer.

The timedelta in question represents precisely 14 24-hours days, and
ignores the possibility that some day in there may suffer a leap
second.

If you add that timedelta to a datetime object, the result may not be
exactly 14*24 hours in the future as measured by civil time (which
includes things like DST transitions).  The result will have the same
local time on the same day of the week two weeks forward.  For
example, if you started with Monday the 6th at 3:45pm, the result will
be Monday the 20th at 3:45;pm.  Period.  The time zone (if any is
attached) is wholly ignored throughout.  If a DST transition occurs
across that period, then it's impossible to say how far removed (as
measured by. say, an independent stopwatch) Monday the 20th at 3:45pm
is from Monday the 6th at 3:45pm without also knowing the month, the
year, and the exact local time zone rules in effect across the period.

It remains unclear to me which of those outcomes _you_ consider to be
"actually 14 days".  But my bet is that you like what Python already
does here (because "tz-naive arithmetic" is exactly what _I_ want in
all my financial code).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Stephen J. Turnbull]

Paul Moore writes:

 > On 27 July 2015 at 15:57, Ronald Oussoren  wrote:
 > > IMHO “+ 1 days” and “+ 24 hours” are two different things.  Date
 > > arithmetic is full of messy things like that.  “+ 1 month” is another
 > > example of that (which the datetime module punts completely
 > > and can be a source of endless bikeshidding).
 > 
 > Precisely.

Er, to be exact, it's an accurate statement of imprecision (although
when talking about time and computation, both "accuracy" and
"precision" are ambiguous).  Fortunately, there's a "tim" in "time"!


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process?

[Ben Finney]

Robert Collins  writes:

> On 21 July 2015 at 00:34, Ben Finney  wrote:
> > Paul Moore  writes:
> >
> >> Again, I'm sorry to pick on one sentence out of context, but it cut
> >> straight to my biggest fear when doing a commit (on any project) -
> >> what if, after all the worrying and consideration I put into doing
> >> this commit, people disagree with me (or worse still, I made a
> >> mistake)? Will I be able to justify what I decided?
> >
> > That seems quite healthy to me. On a collaborative project with
> > effects far beyond oneself, yes, any change *should* be able to be
> > justified when challenged.
>
> Depending on what you mean by justification , this leaves no leeway
> for hunches, feelings, intuition, or grey area changes.

This doesn't address what I've said; or, I've misunderstood what you've
said.

I'm well aware that *most* of the changes we actually work on and
introduce will be based on hunches, feelings, intuition, grey areas,
etc. That can't be expected to disappear.

Indeed, these non-rational ways of reaching a decision are essential to
allow us to act with any kind of speed. Non-rational decision making is
much faster, and necessarily will form the great majority of our
decision making. Good!

What I'm making explicit is: those can't serve as *justification* for
introducing a change. When a change is challenged (by someone to whom we
are answerable), claiming that it just “felt right” is not enough.

I'm not proposing to block every change based on those non-rational
impulses. Those impulses reflect our internalised lessons that we've
learned from experience.

When someone's non-rational decisions prove reliably good *when
challenged* by rational third-party interrogation, we correctly trust
them to make more such decisions.

That's not advocating subjecting a *person* to interrogation, with the
connotations of moral judgement. Be clear: I'm talking only about
interrogating the rational justification for a code change, separate
from judgement of the person.

So: we will inevitably make most of our decisions non-rationally, which
means, among other things, *faster* than explicitly rational decision
making. I don't propose to change that, and our trusted core developers
are not expected to be any exception to this human truth.

It has to be recognised, though, that there must be some third-party
scrutiny, and if no *rational* justification can be presented for a
change – whether tha justification is composed ahead of the change, or
some time afterward, or even at the time of the challenge – then that
change is rather likely to be a poor one.

Again, this is *not* a call to subject every, or even most, changes to
rigorous scrutiny. That would be an intolerably slow and oppressive
environment, which I don't advocate.

What I am rejectiong is the idea, expressed several times in this
thread, that requesting rational justification for a change can be
dismissed out of hand. That's abdicating any accountability, and I was
quite concerned to see that attitute expressed.

No one need feel accountable to me especially, or any other arbitrary
member. Rather, I think it's healthy that core developers feel
accountable to the principle that any change *should* be justifiable,
when challenged by someone with sufficient authority; and that such an
authoritative request is not answered by “it felt right to me”.

> It's also a terrible way to treat people that are contributing their
> own time and effort: assume good faith is a much better starting
> point.

Agreed, we should assume good faith. Most decisions will be reached
non-rationally, and we have no option but to trust some people to make
many non-rational decisions.

Simultaneously, when entrusted with such decisions, we must assume that
any changes we make which can't be justified *when later challenged*
should fall away.

What we mustn't assume is that just because we have made good
non-rational decisions in the past, the next one we make will also be
well-justified.

Especially, we should assume that anyone who *asks* for that rational
justification is also acting in good faith.

-- 
 \  “The only tyrant I accept in this world is the still voice |
  `\  within.” —Mohandas K. Gandhi |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)

[Ben Finney]

"Stephen J. Turnbull"  writes:

> […] The "meta" of "special cases aren't special enough to break the
> rules" is that no design decision that violates it should be dismissed
> as "minor".

Thank you. That dismissal was very upsetting; essentially telling Python
users that their concerns for a clean API in the standard library aren't
worth much to the Python core developers.

> In context of a mailing list, doing so is going to be taken by readers
> as "I know what I'm doing, and you don't know what you're talking
> about, so STFU."

That may not have been the intent. It certainly was how it was received
by some of us here.

> *Both* roles in this comedy of errors are natural, they are inherent
> in human cognition (citations on request), and nobody is to be blamed.

Since it can't seem to be said enough, I agree with what Stephen's
saying here wholeheartedly: the above explications are not intended as
blame, but an explanation of why calls to “stop talking about this, it's
minor” had precisely the opposite effect.

-- 
 \   “Remember: every member of your ‘target audience’ also owns a |
  `\   broadcasting station. These ‘targets’ can shoot back.” —Michael |
_o__)   Rathbun to advertisers, news.admin.net-abuse.email |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

[Paul Moore]
>>>

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

[Chris Barker  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,

It couldn't be _more_ different in three key respects:

1) The leap year rules are algorithmic, while leap seconds are added
at unpredictable times by decree.  That means any attempt to support
them across dozens of platforms also needs to find a way to distribute
& synchronize leap-second info across all the platforms too, over &
over & over again.  Few want to volunteer for yet another never-ending
new task.

2) Leap years visibly effect everyone on the planet who uses a
calendar.  Leap seconds don't.  To the contrary, civil authorities do
all they can to keep leap seconds "out of sight, out of mind".

3) If adding leap seconds had any visible semantic effect in Python,
99.99% of Python users would complain about being bothered with them.
In contrast, removing leap-year support would cause 32.6% of Python
users to complain -  eventually ;-)

> ...
> But leap seconds are the big red herring -- darn few people need them!

Do you?  If not, put your energy instead into something you _do_ need
;-)  But if you do need them, write a patch and try to sneak it by
Guido.

> It's pretty rare, indeed, to be expressing your time in gregorian dates, and 
> also
> care about accuracy down to the seconds over centuries

Python's datetime supports microsecond precision.  Mere seconds are
for wimps ;-)

...

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

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

As mentioned earlier, uniform patterns in local time can be -
typically because of DST transitions - "lumpy" in UTC.  Like "every
Friday at 3pm in time zone T" is trivial to deal with _in_ T using
"naive" datetime arithmetic, but the corresponding datetimes in UTC
are irregular (the number of hours between successive corresponding
UTC times can slobber around between 167 and 169)..  There are no
one-size-fits-all solutions here.



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

_Users_ care.  That's why the tzname() method exists.  When they
display it, it's at best confusing if the name they see doesn't match
the name they expect.

But I'm not sure _how_ the name can get out of synch.  Upon
reflection, the specific case I had in mind was actually caused by
incorrect coding of a tzinfo subclass.  Maybe that's the only way a
wrong name can be returned (apart from incorrect names in the base
zoneinfo data files).


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

The "every Friday at 3pm in time zone T" example comes to mind:
trying to do _that_ arithmetic in UTC is an irregular mess.

More generally, as mentioned before, the current fromutc()
implementation can't deal reliably with a time zone changing its
standard UTC offset (if it isn't clear, fromutc() is used in
astimezone(), which latter is used for time zone conversions).

Paul, do you have something else in mind for this one?


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

But in "naive time", the difference between 3pm one day and 3pm the
next day is also always 24 hours, 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.

To the contrary, for a dozen years "+ timedelta(days=1)" HAS computed
"this time tomorrow", and exactly the same as "+ timedelta(hours=24)".
  Those have never done anything other in Python.


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

Re: [Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

On Tue, Jul 28, 2015 at 12:03 AM, Tim Peters  wrote:
> timedelta objects only store days, seconds, and microseconds,

Except that they don't actually store days. They store 24 hour
periods, which, because of timezones changing, is not the same thing.
This is also clearly intended, for example timedelta allows floats,
and will convert the fraction into seconds. And as you have repeated
many times now, the datetime module's arithmetic is "naive" ie, it
assumes that one day is always 24 hours. The problem with that
assumption is that it isn't true.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

On Tue, Jul 28, 2015 at 12:11 AM, Ronald Oussoren
 wrote:
> I totally agree with that, having worked on applications that had to deal 
> with time a lot and including some where the end of a day was at 4am the 
> following day.  That app never had to deal with DST because not only are the 
> transitions at night, the are also during the weekend.

If you don't have to deal with DST, then you don't have to have
tzinfo's in your date objects. You can have just truly naive objects
without DST information, and this will work just fine.
I think most people's expectations are that datetime's that *are* time
zone aware, should actually deal correctly with those time zones.

> It might be nice to have time zone aware datetime objects with the right(TM) 
> semantics, but those can and should not replace the naive objects we know and 
> love.

Yes, they most certainly should.
I will try to shut up now, but let me be clear on that the time zone
support as it stands now is intentionally broken. Not naive, *broken*.
All the usecases people have here for supporting "naive" objects would
work just as well if they actually used naive objects, ie datetimes
with no timezone info. If you explicitly do NOT want the
datetimeobject to care about timezones, then you should not add a
timezone to the object.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence  wrote:
> To me a day is precisely 24 hours, no more, no less.

OK.

> In my mission critical code, which I use to predict my cashflow, I use code
> such as.
>
> timedelta(days=14)
>
> Is somebody now going to tell me that this isn't actually two weeks?

Yes, I'm telling you that, now.

The two claims "One day is always precisely 24 hours" and "14 days is
two weeks" are not both true. You have to choose one.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Ethan Furman]

On 07/27/2015 10:08 PM, Lennart Regebro wrote:

On Tue, Jul 28, 2015 at 12:11 AM, Ronald Oussoren wrote:



It might be nice to have time zone aware datetime objects with the right(TM)
 semantics, but those can and should not replace the naive objects we know
 and love.


Yes, they most certainly should.
I will try to shut up now, but let me be clear on that the time zone
support as it stands now is intentionally broken. Not naive, *broken*.
All the usecases people have here for supporting "naive" objects would
work just as well if they actually used naive objects, ie datetimes
with no timezone info. If you explicitly do NOT want the
datetimeobject to care about timezones, then you should not add a
timezone to the object.


Lennart, are you saying you would leave naive objects alone, and "fix" the 
tz-aware objects only?

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

On Tue, Jul 28, 2015 at 7:27 AM, Ethan Furman  wrote:
> Lennart, are you saying you would leave naive objects alone, and "fix" the
> tz-aware objects only?

Naive objects are not broken, so they can't be fixed. Which I guess
means "yes". :-)

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Ethan Furman]

On 07/27/2015 10:47 PM, Lennart Regebro wrote:

On Tue, Jul 28, 2015 at 7:27 AM, Ethan Furman wrote:



Lennart, are you saying you would leave naive objects alone, and "fix" the
tz-aware objects only?


Naive objects are not broken, so they can't be fixed. Which I guess
means "yes". :-)


Ah, cool!  I'm on board with that!

So the next question is how much of the current tz-aware datetime's behavior 
can be changed?

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

[Tim]
>> timedelta objects only store days, seconds, and microseconds,

[Lennart Regebro ]
> Except that they don't actually store days. They store 24 hour
> periods,

Not really.  A timedelta is truly an integer number of microseconds,
and that's all.  The internal division into days, seconds and
microseconds is a mixed-radix scheme designed to make extracting some
common units of duration more efficient than by using division on a
single long integer all the time.  That's an implementation detail,
although one that is exposed.

> which, because of timezones changing, is not the same thing.

24 hours is 24 hours at any time in _any_ time zone, ignoring leap
seconds.  timedeltas are durations, not points in time.  "time zones"
make no sense applied to durations.

> This is also clearly intended, for example timedelta allows floats,
> and will convert the fraction into seconds.

I suspect I'm missing your meaning here.  Have a specific example to
illustrate it?  For example, are you talking about things like this?

>>> timedelta(weeks=0.5)
datetime.timedelta(3, 43200)

If so, what of it?  A week is _defined_ to be 7 days in timedelta,
where a day is in turn defined to be 24 hours, where ... until you
finally get down to microseconds.  None of this has anything to do
with points in time or time zones.  It's entirely about duration.  In
the example, a week turns out to be 6048 microseconds.  Half
of that is 3024 microseconds.  Convert that into mixed-radix
days-seconds-microseconds representation, and you're left with 3 days
and 43200 seconds (with 0 microseconds left over).  I don't see
anything remarkable about any of that - perhaps you just object to the
use of the _word_ "day" in this context?  It's just a word, and
there's nothing remarkable either about viewing a duration of "a day"
as being a duration of "24 hours".  It's a timedelta - a duration.
UTC offsets of any kind have nothing to do with pure durations, they
only have to do with points in time.  Calling "a day" 24 hours _in the
context_ of a timedelta is not only unobjectionable, calling a day
anything else in this entirely zone-free context would be insane ;-)

> And as you have repeated many times now, the datetime module's
> arithmetic is "naive"

But only when staying within a single time zone.  For example, if dt1
and dt2 have different tzinfo members, dt1 - dt2 acts as if both were
converted to UTC first before doing subtraction.  "Naive time" doesn't
come into play _across_ time zones, only _within_ a time zone.  When
mixing time zones, there's no plausible justification for ignoring
either of 'em.  So they're not ignored then.

> ie, it assumes that one day is always 24 hours.

That's really not what it's doing, although the analogy is sometimes
used in explanations.  What somedatetime+timedelta really does is
simpler than that:  it adds the number of microseconds represented by
the timedelta to somedatetime, being careful with carries across the
assorted time and date components.  That's all.  There are no
assumptions about what any of it "means".  What it _doesn't_ do is
consult the tzinfo member about anything, and _that's_ the true source
of your complaints.  It so happens that, yes, naive datetime
arithmetic does always treat "a day" as 24 hours (and "a week" as 7
days, and "a minute" as 60 seconds, and so on), but not really because
it's assuming anything about what days, weeks, etc "mean".  It's
working with microseconds, and it's giving the result you'd get from
working on somedatetime.replace(tzinfo=None) instead, except it
doesn't actually remove the tzinfo member.

> The problem with that assumption is that it isn't true.

There isn't really an assumption here.  "Naive time" has no concept of
"time zone", which isn't "an assumption" so much as a _requirement_ of
the design.  You can legitimately object that this requirement is at
odds with reality in some cases.  And that's true:  it is.  But that's
also been known since the start.  It's _intentionally_ at odds with
reality in some cases, because it was believed that a simpler
approximation to reality would be most useful most often to most
applications and programmers.  And you've heard from some of them
here.

Note that the same principle is at work in other aspects of datetime's
design.  For example, the proleptic Gregorian calendar is itself a
simplified approximation to reality.  In historical terms it's a
relatively recent invention, and even now it's not used in much of the
world.  So what?  It does little harm to most applications to pretend
that, e.g., 3 March 1012 is a valid Gregorian date, but simplifies
their lives, although some obsessed calendar wonk may be outraged by
such a bold fiction ;-)

It's all a "practicality beats purity" thing, but weaker than many
such things, because in this case _sometimes_ naive arithmetic is
_not_ the most practical thing.  It has been in every dateime
application I ever wrote, but I recognize that's not the univer

Re: [Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

On Tue, Jul 28, 2015 at 8:11 AM, Tim Peters  wrote:
> [Tim]
>>> timedelta objects only store days, seconds, and microseconds,
>
> [Lennart Regebro ]
>> Except that they don't actually store days. They store 24 hour
>> periods,
>
> Not really.  A timedelta is truly an integer number of microseconds,
> and that's all.

That's what I said. Timedeltas, internally assume that 1 day is 24
hours. Or 8640 microseconds. That's the assumption internally in
the timedelta object.

The problem with that being that in the real world that's not true.

> 24 hours is 24 hours at any time in _any_ time zone, ignoring leap
> seconds.  timedeltas are durations, not points in time.  "time zones"
> make no sense applied to durations.

My point exactly.

And should not then adding 8640 microseconds to a datetime
actually result in a datetime that happens 8640 microseconds
later?

>> ie, it assumes that one day is always 24 hours.
>
> That's really not what it's doing

That is really exactly what the timedelta is doing, as you yourself,
just a few lines above say.

> used in explanations.  What somedatetime+timedelta really does is
> simpler than that:  it adds the number of microseconds represented by
> the timedelta to somedatetime,

No it doesn't.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com