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
Ben Finney writes:
> I've made a clear distinction between the need to *be able to*
> justify a change, versus arbitrary demands to do so by arbitrary
> members.
>
> The latter is what you're arguing against, and of course I agree. I've
> never advocated that.
Sure, but the former, when st
On 29 July 2015 at 00:17, Ben Finney wrote:
> I've made a clear distinction between the need to *be able to* justify a
> change, versus arbitrary demands to do so by arbitrary members.
>
> The latter is what you're arguing against, and of course I agree. I've
> never advocated that.
The thing we
[Ł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
Thanks Brett :-) I agree that a dedicated mailing list is a good idea.
Please stop flooding python-dev and move open discussions to the new
mailing list. By the way, I suggest to open multiple threads since
multiple topics were discussed in the same thread. So it became
difficult to follow the dis
https://mail.python.org/mailman/listinfo/datetime-sig
In the future feel free to redirect date- and time-related discussions to
the SIG since datetime stuff requires such a specific domain knowledge that
most of us have.
I am also looking for people to be admins of the list. If you're willing to
> 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
I got my MSI built, after numerous modifications to the various build
scripts. the installed file set bears little resemblance to the
official release for the same version, which is a bit of a fail for
the Open-source principle, but it seems nobody cares, so I'll split.
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
Paul Moore writes:
> On 28 July 2015 at 13:35, Ben Finney wrote:
> > People can, do, and probably must make many decisions through
> > non-rational processes. I don't propose to change that.
>
> Good.
>
> > Choices can be made that, when challenged, lack compelling rational
> > justification. I
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 28 July 2015 at 13:35, Ben Finney wrote:
> People can, do, and probably must make many decisions through
> non-rational processes. I don't propose to change that.
Good.
> Choices can be made that, when challenged, lack compelling rational
> justification. I do propose that such a challenge sh
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
Paul Moore writes:
> But isn't the whole *point* of a non-rational decision (as you
> describe it) that you *can't* articulate your reasons for making that
> decision.
You've conflated the process used to make a decision, with the
justifications that support that decision.
Those are separate. W
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
On 28 July 2015 at 05:18, Ben Finney wrote:
>
> 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
[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
34 matches
Mail list logo
