[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 one day to
On 28 Jul 2015, at 03:13, Tres Seaver tsea...@palladion.com 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
On Wed, 29 Jul 2015 06:26:44 +0200, Lennart Regebro rege...@gmail.com wrote:
On Tue, Jul 28, 2015 at 10:26 PM, Tim Peters tim.pet...@gmail.com 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).
[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 Python
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
[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
[Lennart Regebro rege...@gmail.com]
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.
On Tue, Jul 28, 2015 at 10:25 AM, Łukasz Rekucki lreku...@gmail.com 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
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 point --
On Tue, Jul 28, 2015 at 8:11 AM, Tim Peters tim.pet...@gmail.com wrote:
[Tim]
timedelta objects only store days, seconds, and microseconds,
[Lennart Regebro rege...@gmail.com]
Except that they don't actually store days. They store 24 hour
periods,
Not really. A timedelta is truly an
On Tue, Jul 28, 2015 at 9:00 AM, Tim Peters tim.pet...@gmail.com 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
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 cheated.
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
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 24 hours to
On 28/07/2015 13:35, Lennart Regebro wrote:
On Tue, Jul 28, 2015 at 1:55 PM, Mark Lawrence breamore...@yahoo.co.uk 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
On Tue, Jul 28, 2015 at 3:17 PM, Mark Lawrence breamore...@yahoo.co.uk 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
On Tue, Jul 28, 2015 at 10:06 PM, Mark Lawrence breamore...@yahoo.co.uk wrote:
On 28/07/2015 06:21, Lennart Regebro wrote:
On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence breamore...@yahoo.co.uk
wrote:
To me a day is precisely 24 hours, no more, no less.
In my mission critical code, which I
-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 06:21, Lennart Regebro wrote:
On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence breamore...@yahoo.co.uk 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
On Tue, Jul 28, 2015 at 1:55 PM, Mark Lawrence breamore...@yahoo.co.uk 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
On Tue, Jul 28, 2015 at 1:55 PM, Mark Lawrence breamore...@yahoo.co.uk 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
On 28/07/2015 03:15, Tim Peters wrote:
[Mark Lawrence breamore...@yahoo.co.uk]
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
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
On 28/07/2015 07:54, Lennart Regebro wrote:
On Tue, Jul 28, 2015 at 8:11 AM, Tim Peters tim.pet...@gmail.com wrote:
[Tim]
timedelta objects only store days, seconds, and microseconds,
[Lennart Regebro rege...@gmail.com]
Except that they don't actually store days. They store 24 hour
periods,
On Tue, Jul 28, 2015 at 10:26 PM, Tim Peters tim.pet...@gmail.com 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
On 28/07/2015 16:47, Chris Angelico wrote:
On Tue, Jul 28, 2015 at 10:06 PM, Mark Lawrence breamore...@yahoo.co.uk wrote:
On 28/07/2015 06:21, Lennart Regebro wrote:
On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence breamore...@yahoo.co.uk
wrote:
To me a day is precisely 24 hours, no more, no
On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence breamore...@yahoo.co.uk
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 breamore...@yahoo.co.uk wrote:
My cashflow forecast doesn't give two hoots
On 28 Jul 2015, at 03:13, Tres Seaver tsea...@palladion.com 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
[Tim]
timedelta objects only store days, seconds, and microseconds,
[Lennart Regebro rege...@gmail.com]
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
[Łukasz Rekucki lreku...@gmail.com]
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 rege...@gmail.com]
Well, the separation is pretty clear already.
I
On Tue, Jul 28, 2015 at 7:27 AM, Ethan Furman et...@stoneleaf.us 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: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!
On Mon, 27 Jul 2015 02:09:19 -0500, Tim Peters tim.pet...@gmail.com 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
On Jul 27 2015, Lennart Regebro rege...@gmail.com 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
On 27 July 2015 at 14:59, R. David Murray rdmur...@bitdance.com 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
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
On Mon, Jul 27, 2015 at 10:54:02AM +0200, Lennart Regebro wrote:
On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore p.f.mo...@gmail.com 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
: 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 p.f.mo...@gmail.com wrote:
I'm confused by your position. If it's 7am on the clock behind me,
right now, then how (under the model
On 28 July 2015 at 00:27, Steve Dower steve.do...@microsoft.com 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
On Tue, Jul 28, 2015 at 12:13 AM, Steven D'Aprano st...@pearwood.info 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 p.f.mo...@gmail.com wrote:
I'm confused by your position. If it's 7am on the clock behind me,
right now,
On Mon, Jul 27, 2015 at 4:27 PM, Steve Dower steve.do...@microsoft.com 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
On Mon, Jul 27, 2015 at 5:12 PM, Paul Moore p.f.mo...@gmail.com 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
On 2015-07-27 15:59, Paul Moore wrote:
On 27 July 2015 at 14:59, R. David Murray rdmur...@bitdance.com 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.
On Mon, Jul 27, 2015 at 4:13 PM, Steven D'Aprano st...@pearwood.info 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
On Jul 27, 2015, at 9:13 AM, Steven D'Aprano st...@pearwood.info 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 p.f.mo...@gmail.com wrote:
I'm confused by your position. If it's 7am on the clock behind me,
right now,
On Mon, Jul 27, 2015 at 3:59 PM, R. David Murray rdmur...@bitdance.com 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
On 27 July 2015 at 15:37, Lennart Regebro rege...@gmail.com 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
On 2015-07-27 15:46, Lennart Regebro wrote:
On Mon, Jul 27, 2015 at 4:13 PM, Steven D'Aprano st...@pearwood.info 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
On Mon, Jul 27, 2015 at 10:59 AM, Paul Moore p.f.mo...@gmail.com 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
On Mon, Jul 27, 2015 at 11:42 AM, Ryan Hiebert r...@ryanhiebert.com 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
On Mon, Jul 27, 2015 at 4:45 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 28 July 2015 at 00:27, Steve Dower steve.do...@microsoft.com 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
On Mon, 27 Jul 2015 16:37:47 +0200, Lennart Regebro rege...@gmail.com wrote:
On Mon, Jul 27, 2015 at 3:59 PM, R. David Murray rdmur...@bitdance.com
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
On 27 July 2015 at 16:26, MRAB pyt...@mrabarnett.plus.com 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
On Mon, Jul 27, 2015 at 12:15 PM, Nikolaus Rath nikol...@rath.org wrote:
On Jul 27 2015, Lennart Regebro rege...@gmail.com 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
On 27 July 2015 at 15:57, Ronald Oussoren ronaldousso...@mac.com 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
On 27/07/2015 15:45, Nick Coghlan wrote:
On 28 July 2015 at 00:27, Steve Dower steve.do...@microsoft.com 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
On Mon, Jul 27, 2015 at 6:15 PM, Nikolaus Rath nikol...@rath.org wrote:
On Jul 27 2015, Lennart Regebro rege...@gmail.com 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
On Tue, Jul 28, 2015 at 12:57 AM, Ronald Oussoren
ronaldousso...@mac.com 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
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
On Mon, Jul 27, 2015 at 6:42 PM, Alexander Belopolsky
alexander.belopol...@gmail.com 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.
On 27 Jul 2015, at 04:04, Tim Peters tim.pet...@gmail.com 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
On Mon, Jul 27, 2015 at 12:30 PM, Lennart Regebro rege...@gmail.com wrote:
On Mon, Jul 27, 2015 at 6:15 PM, Nikolaus Rath nikol...@rath.org wrote:
On Jul 27 2015, Lennart Regebro rege...@gmail.com wrote:
(The *first* option)
That you add one hour to it, and the datetime moves forward one
On 27 July 2015 at 17:30, Lennart Regebro rege...@gmail.com 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
[Ronald Oussoren ronaldousso...@mac.com]
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
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
On 7/27/2015 3:09 AM, Tim Peters wrote:
[Paul Moore p.f.mo...@gmail.com]
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 rege...@gmail.com]
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
[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 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
[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 ros...@gmail.com]
No leap second support, presumably. Also feature?
Absolutely none, and absolutely a feature,
On Tue, Jul 28, 2015 at 4:49 AM, Tim Peters tim.pet...@gmail.com 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 Mon, Jul 27, 2015 at 11:55 AM, Terry Reedy tjre...@udel.edu wrote:
I think using the word 'naive' is both inaccurate and a mistake.
snip
'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
[Terry Reedy tjre...@udel.edu]
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
On Mon, Jul 27, 2015 at 12:07 PM, Chris Angelico ros...@gmail.com 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
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
[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
On Mon, Jul 27, 2015 at 7:49 AM Lennart Regebro rege...@gmail.com wrote:
On Mon, Jul 27, 2015 at 4:45 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 28 July 2015 at 00:27, Steve Dower steve.do...@microsoft.com wrote:
Am I the only one feeling like this entire thread should be moved to
[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 jon+python-...@unequivocal.co.uk]
This usage of time zone is confusing.
Ha! _All_ usages of time
[Brett Cannon br...@python.org]
\ 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
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
On 27 July 2015 at 22:10, Tim Peters tim.pet...@gmail.com 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
-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
On Mon, Jul 27, 2015 at 9:47 PM, Ethan Furman et...@stoneleaf.us 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
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
On 7/27/2015 1:42 PM, Lennart Regebro wrote:
On Mon, Jul 27, 2015 at 9:47 PM, Ethan Furman et...@stoneleaf.us 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
On 27 jul. 2015, at 20:49, Tim Peters tim.pet...@gmail.com wrote:
[Ronald Oussoren ronaldousso...@mac.com]
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
On Mon, Jul 27, 2015 at 5:13 PM, Tim Peters tim.pet...@gmail.com wrote:
[Brett Cannon br...@python.org]
\ 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
On Mon, Jul 27, 2015 at 12:47 PM, Ethan Furman et...@stoneleaf.us 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
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
[Tres Seaver tsea...@palladion.com]
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
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
-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
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
[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
[Mark Lawrence breamore...@yahoo.co.uk]
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
-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
On Mon, Jul 27, 2015 at 2:10 PM, Tim Peters tim.pet...@gmail.com wrote:
Guido will never allow any aspect of leap seconds into the core,
really? that is a shame (and odd) -- it's a trick, because we don't know
what leap seconds will be needed in the future, but other than that, it's
not
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
On Tue, Jul 28, 2015 at 12:03 AM, Tim Peters tim.pet...@gmail.com 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
On Tue, Jul 28, 2015 at 12:11 AM, Ronald Oussoren
ronaldousso...@mac.com 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
1 - 100 of 195 matches
Mail list logo
