[Lennart Regebro]
\>>> I have yet to see a use case for that.
[Tim]
>> Of course you have. When you address them, you usually dismiss them
>> as "calendar operations" (IIRC).
'[Lennart]
> Those are not usecases for this broken behaviour.
>
> I agree there is a usecase for where you want to add
On Wed, 29 Jul 2015 06:26:44 +0200, Lennart Regebro wrote:
> On Tue, Jul 28, 2015 at 10:26 PM, Tim Peters wrote:
> >> I have yet to see a use case for that.
> >
> > Of course you have. When you address them, you usually dismiss them
> > as "calendar operations" (IIRC).
>
> Those are not usecase
> On 28 Jul 2015, at 03:13, Tres Seaver wrote:
>
> -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
>>
On Tue, Jul 28, 2015 at 10:26 PM, Tim Peters wrote:
>> I have yet to see a use case for that.
>
> Of course you have. When you address them, you usually dismiss them
> as "calendar operations" (IIRC).
Those are not usecases for this broken behaviour.
I agree there is a usecase for where you wan
[Łukasz Rekucki ]
>> Maybe instead of trying to decide who is "wrong" and which approach is
>> "broken", Python just needs a more clear separation between timezone
>> aware objects and "naive" ones?
[Lennart Regebro ]
> Well, the separation is pretty clear already.
I preemptively ;-) agreed with
> On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence
> wrote:
> To me a day is precisely 24 hours, no more, no less.
Start with this line. Then proceed:
On Wed, Jul 29, 2015 at 3:01 AM, Mark Lawrence wrote:
> My cashflow forecast doesn't give two hoots how many hours there are in two
> weeks, whic
On 28/07/2015 16:47, Chris Angelico wrote:
On Tue, Jul 28, 2015 at 10:06 PM, Mark Lawrence wrote:
On 28/07/2015 06:21, Lennart Regebro wrote:
On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence
wrote:
To me a day is precisely 24 hours, no more, no less.
In my mission critical code, which I use
> On 28 Jul 2015, at 03:13, Tres Seaver wrote:
>
> -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
>>
On Tue, Jul 28, 2015 at 10:06 PM, Mark Lawrence wrote:
> On 28/07/2015 06:21, Lennart Regebro wrote:
>>
>> On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence
>> wrote:
>>>
>>> To me a day is precisely 24 hours, no more, no less.
>>> In my mission critical code, which I use to predict my cashflow, I u
On Tue, Jul 28, 2015 at 3:17 PM, Mark Lawrence wrote:
> Tim asked for my definition of two weeks so I've given it. With respect to
> that in reality this is true, for me, with my application, making my
> statement above correct. For my application we could go from GMT to BST and
> back on succes
On 28/07/2015 13:35, Lennart Regebro wrote:
On Tue, Jul 28, 2015 at 1:55 PM, Mark Lawrence wrote:
One week == 7 days == 7 * 24 hours
Two weeks = 2 * (one week)
Right, and that of course is not true in actual reality. I know you
are not interested in DST, but with a timezone that has DST, two
On Tue, Jul 28, 2015 at 1:55 PM, Mark Lawrence wrote:
> Correct. What I would like to know is how many people are in my position,
> how many people are in the situation of needing every possible combination
> of dates, times, daylight saving, local time zone rules and anything else
> you can thin
On Tue, Jul 28, 2015 at 1:55 PM, Mark Lawrence wrote:
> One week == 7 days == 7 * 24 hours
> Two weeks = 2 * (one week)
Right, and that of course is not true in actual reality. I know you
are not interested in DST, but with a timezone that has DST, two times
a year, the above statement is wrong.
On 28/07/2015 05:26, Tim Peters wrote:
Python's datetime supports microsecond precision. Mere seconds are
for wimps ;-)
Microseconds are for wimps https://bugs.python.org/issue22117 :)
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
On 28/07/2015 07:54, Lennart Regebro wrote:
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 a
On 28/07/2015 06:21, Lennart Regebro wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/27/2015 09:36 PM, Tim Peters wrote:
> 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
On 28/07/2015 03:15, Tim Peters wrote:
[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
On Mon, Jul 27, 2015 at 04:28:48PM -0700, Chris Barker wrote:
> > 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 p
I was going to jump in and explain the rationale for the original design
and why we shouldn't change it, but I just realized that Tim Peters has
been explaining this position already, and instead I am going to mute this
thread. Please switch to python-ideas or to the new datetime-specific list
(if
On Tue, Jul 28, 2015 at 10:25 AM, Łukasz Rekucki wrote:
> Maybe instead of trying to decide who is "wrong" and which approach is
> "broken", Python just needs a more clear separation between timezone
> aware objects and "naive" ones?
Well, the separation is pretty clear already. Tim wants to have
Tres Seaver writes:
> - 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.
I gather you've never been a prof who told a student with aggravated
"writer's block" she had 2
Hi,
As it's very hard to keep up with the pace of this thread, instead of
addressing any particular response I would like to add some
(hopefully) useful context.
While Java was historically known for the worst date/time handling
ever (e.g. months starting with 0), in Java 8 a new module was added
[Lennart Regebro ]
> Of course, I meant datetime objects.
> In everything else, I stand by my original claim. If you want naive
> datetime obejcts, you should use naive datetime objects.
That's tautological ("if you want X, you should use X"). I'm not sure
what you intended to say. But it's a fa
Terry Reedy writes:
> 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
[delightful new insight elided, all summarized by what remains ;-) ]
[Tim]
>> What somedatetime+timedelta really does is simpler than that: it
>> adds the number of microseconds represented by the timedelta to
>> somedatetime,
[Lennart]]
> No it doesn't.
Lennart, I wrote the code. Both the Pyt
On Tue, Jul 28, 2015 at 9:00 AM, Tim Peters wrote:
> [Lennart Regebro]
>> If you don't have to deal with DST, then you don't have to have
>> tzinfo's in your date objects.
>
> There are no tzinfos on date objects. I assume Ronald is talking
> about datetime objects.
Of course, I meant datetime o
[Ronald Oussoren]
>> 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
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,
[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
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, coo
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
__
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
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
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
> transi
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 timed
[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 yea
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
[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
>
[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
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(hou
-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 z
-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)
>
>
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 t
> 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 l
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 t
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 s
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 inte
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 tha
> 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 arithm
[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 confir
-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 (tho
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 (ak
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" bi
[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:
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 8640
[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
> re
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
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
[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 ;-)
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 tomor
[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
[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
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 sear
[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
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.
-CH
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
>>> 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
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
___
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 t
[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 i
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
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 t
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 bikeshi
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 exper
> 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
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).
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?
>
>
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-
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 d
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 t
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
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 th
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
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
> 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
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 representatio
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
app
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 thin
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
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 i
> 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 propo
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
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 com
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
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.
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 wording
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
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
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,
1 - 100 of 195 matches
Mail list logo
