Jon Ribbens wrote:
> Steven Bethard <[EMAIL PROTECTED]> wrote:
>
>>We know that:
>>date(2006, 1, 1) *Includes* datetime(2006, 1, 1, 0, 0, 1)
>
> Oh dear. You've fallen at the first hurdle. We do not know that.
Translated into English, this is saying "The 1st of January
2006 includes the t
Collin Winter <[EMAIL PROTECTED]> wrote:
> Please find or write a package that makes the assumptions you want,
> since datetime clearly isn't the module you want.
Datetime clearly *is* the module I want. It already makes the
assumptions I want, I just want it to make them consistently.
___
On 3/11/07, Jon Ribbens <[EMAIL PROTECTED]> wrote:
[snark]
> It makes pragmatic assumptions about
> what people mean when they use date arithmetic. They might not be the
> assumptions you want, but then it's probably not the module you want.
Please find or write a package that makes the assumption
Steven Bethard <[EMAIL PROTECTED]> wrote:
> I was trying to minimize the extent of this already too long thread,
> assuming you could go do the reading I referred you to if you were
> really interested in the answer.
There's nothing to be gained by being patronising.
> I still encourage you to re
Jon Ribbens wrote:
> > Robert Brewer <[EMAIL PROTECTED]> wrote:
> > > One solution that just occurred to me -- and that
> > > skirts the issue of choosing an interpretation --
> > > is that, when comparing date and datetime objects,
> > > the datetime's .date() method is called and the
> > > result
On 3/11/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> I do not really understand proper temporal intervals. But I am
> interested what "temporal interval logic" has to say about this
> problem:
>
> def get_most_recent_articles(articles, cutoff_date):
> recent_articles = []
> for article
On 3/11/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 3/11/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > I've another idea. Date and datetime objects are compared by date. The
> > date object for a given date is always smaller than the datetime for the
> > same day - even for midnight.
>
On 3/11/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Jon Ribbens schrieb:
> > I see you snipped without response my request to back up your claim
> > that "assuming that a date() is a datetime() with a time of midnight
> > will clearly break that logic".
>
> I've another idea. Date and datetim
Jon Ribbens schrieb:
> I see you snipped without response my request to back up your claim
> that "assuming that a date() is a datetime() with a time of midnight
> will clearly break that logic".
I've another idea. Date and datetime objects are compared by date. The
date object for a given date is
On 3/10/07, Jon Ribbens <[EMAIL PROTECTED]> wrote:
> I see you snipped without response my request to back up your claim
> that "assuming that a date() is a datetime() with a time of midnight
> will clearly break that logic".
>
> Am I to assume you cannot back it up?
I was trying to minimize the e
On Sun, Mar 11, 2007 at 11:02:39AM -0500, Tony Nelson wrote:
> Apple's old MacOS had a very flexible LongDateRecord and date utilities.
> Nearly anything one could do to a date had a useful meaning. Perhaps
> Python should be different, but I've found Apple's date calculations and
> date parsing t
At 5:45 PM +1300 3/11/07, Greg Ewing wrote:
>Jon Ribbens wrote:
>
>> What do you feel "next Tuesday plus 12 hours" means? ;-)
>
>I would say it's meaningless. My feeling is that subtracting
>two dates should give an integer number of days, and that is
>all you should be allowed to add to a date.
A
Jon Ribbens wrote:
> What do you feel "next Tuesday plus 12 hours" means? ;-)
I would say it's meaningless. My feeling is that subtracting
two dates should give an integer number of days, and that is
all you should be allowed to add to a date.
--
Greg
I see you snipped without response my request to back up your claim
that "assuming that a date() is a datetime() with a time of midnight
will clearly break that logic".
Am I to assume you cannot back it up?
___
Python-Dev mailing list
Python-Dev@python.o
Tristan Seligmann wrote:
> Unfortunately, it would appear that the Olson tz database contains some
> rather... uh... confusing data. For example:
>
pytz.timezone('Africa/Johannesburg')
>
> # SAST is UTC+2 not UTC+1.5
The tz of Africa/Johannesburg initially started with an offset of 1h30
bef
Tristan Seligmann schrieb:
> pytz.timezone('Africa/Johannesburg')
>
> # SAST is UTC+2 not UTC+1.5
>
pytz.timezone('Etc/GMT+2')._utcoffset
> datetime.timedelta(-1, 79200)
> # I thought I asked for GMT+2, not GMT-2
>
>
> ---
* Christian Heimes <[EMAIL PROTECTED]> [2007-03-10 03:58:27 +0100]:
> >From the README.txt
> pytz brings the Olson tz database into Python. This library allows
> accurate and cross platform timezone calculations using Python 2.3
> or higher. It also solves the issue of ambiguous times at the end
>
Jon Ribbens wrote:
> So you're deciding that a 'date' is 'the entire of that day', except
> when you subtract two of them, when it suddenly means something else? ;-)
No, you're considering dates to be discrete entities,
like integers. You wouldn't use the same reasoning to
argue that the differen
On 3/10/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 3/9/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > Collin Winter schrieb:
> > > I can't say I'm well-versed in the intricacies of date/time issues,
> > > but what you say makes sense. This is exactly why I brought this patch
> > > up he
On 3/10/07, Jon Ribbens <[EMAIL PROTECTED]> wrote:
> Steven Bethard <[EMAIL PROTECTED]> wrote:
> > I still don't see why my more careful comparison would be bad for any
> > of your code. Could you give an example where it would be bad for all
> > the following to be False::
> > date(2006, 1, 1
On 3/10/07, Robert Brewer <[EMAIL PROTECTED]> wrote:
> On 3/9/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > > On the subject of datetime enhancements, I came
> > > across an SF patch (#1673403) the other day that
> > > proposed making it possible to compare date and
> > > datetime objects.
>
Steven Bethard <[EMAIL PROTECTED]> wrote:
> I don't see why the docs can't be explicit about what subtraction
> means given that there are a number of possible interpretations.
I don't see why the docs can't be explicit about what comparison
means given that there are a number of possible interpre
On 3/10/07, Jon Ribbens <[EMAIL PROTECTED]> wrote:
> Steven Bethard <[EMAIL PROTECTED]> wrote:
> > Using the .date() is fine when the year/month/day doesn't match. So
> > the following are fine::
> > datetime.datetime(2005, 1, 1, 0, 0, 0) < datetime.date(2006, 1, 1)
> > datetime.datetime(2
Robert Brewer <[EMAIL PROTECTED]> wrote:
>> One solution that just occurred to me -- and that
>> skirts the issue of choosing an interpretation --
>> is that, when comparing date and datetime objects,
>> the datetime's .date() method is called and the
>> result of that call is c
On 3/9/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > On the subject of datetime enhancements, I came
> > across an SF patch (#1673403) the other day that
> > proposed making it possible to compare date and
> > datetime objects.
>
> One solution that just occurred to me -- and that
> skirts the
On 3/9/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Collin Winter schrieb:
> > I can't say I'm well-versed in the intricacies of date/time issues,
> > but what you say makes sense. This is exactly why I brought this patch
> > up here : )
>
> Oh h...! Seems like I've opened a can of worms here.
Christian Heimes <[EMAIL PROTECTED]> wrote:
> > What do you feel "next Tuesday plus 12 hours" means? ;-)
>
> First thought: It's nonsense! Nobody would say that. ;)
>
> Second though: Tuesday noon (12h after the beginning of Tuesday)
I agree with you entirely. Your suggestions correspond to 'thr
Jon Ribbens schrieb:
> What do you feel "next Tuesday plus 12 hours" means? ;-)
First thought: It's nonsense! Nobody would say that. ;)
Second though: Tuesday noon (12h after the beginning of Tuesday)
Christian
___
Python-Dev mailing list
Python-Dev@
Christian Heimes <[EMAIL PROTECTED]> wrote:
> Jon Ribbens schrieb:
> > So you're deciding that a 'date' is 'the entire of that day', except
> > when you subtract two of them, when it suddenly means something else? ;-)
>
> It makes kinda sense although it looks like a contradiction at first.
>
> T
Jon Ribbens schrieb:
> So you're deciding that a 'date' is 'the entire of that day', except
> when you subtract two of them, when it suddenly means something else? ;-)
It makes kinda sense although it looks like a contradiction at first.
The common linguistic usage of dates in English and German:
Steven Bethard <[EMAIL PROTECTED]> wrote:
> Using the .date() is fine when the year/month/day doesn't match. So
> the following are fine::
> datetime.datetime(2005, 1, 1, 0, 0, 0) < datetime.date(2006, 1, 1)
> datetime.datetime(2007, 1, 1, 0, 0, 0) > datetime.date(2006, 1, 1)
> It's *not*
On 03/09/2007 08:56 PM, Martin v. Löwis wrote:
--
Sjoerd Mullender
> Christian Heimes schrieb:
>> BJörn Lindqvist schrieb:
>>> I think it should be a ValueError, given that the programmer is very
>>> likely to further use the returned timestamp to for example insert
>>> stuff in a database. Unix t
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> At 09:20 PM 3/9/2007 +, Jon Ribbens wrote:
> >If you want the answer to be "the entire of that day" then you need
> >to alter the datetime module so that, e.g. subtracting 2007-03-08
> >from 2007-03-09 does not return "one day" as currently, but ret
Christian Heimes wrote:
>>From the README.txt
> pytz brings the Olson tz database into Python. This library allows
> accurate and cross platform timezone calculations using Python 2.3
> or higher. It also solves the issue of ambiguous times at the end
> of daylight savings, which you can read more
André Malo schrieb:
> But I think, pytz has no place in the stdlib anyway, because it has
> reasonably different release cycles (every time the timezone tables
> change).
The release cycles are a possible issue but what about PEP 297?
http://www.python.org/dev/peps/pep-0297/ It sounds like a per
Brett Cannon schrieb:
> What is wrong with datetime's tzinfo objects? You need to show why
> datetime is not sufficient and why fixing it is not worth it and how
> it is better to bring in another chunk of code. And then we can
> discuss code standards, the author of PyTz stepping forward to
> co
On 3/9/07, André Malo <[EMAIL PROTECTED]> wrote:
> * Brett Cannon wrote:
>
> > On 3/9/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > > * What do you think about including PyTz in the Python core? PyTz is
> > > really, REALLY useful when one has to deal with time zones.
> > > http://pytz.sourc
* Brett Cannon wrote:
> On 3/9/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > * What do you think about including PyTz in the Python core? PyTz is
> > really, REALLY useful when one has to deal with time zones.
> > http://pytz.sourceforge.net/
>
> What is wrong with datetime's tzinfo objects
On 3/9/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Collin Winter schrieb:
> > I can't say I'm well-versed in the intricacies of date/time issues,
> > but what you say makes sense. This is exactly why I brought this patch
> > up here : )
>
> Oh h...! Seems like I've opened a can of worms here.
On Sat, 10 Mar 2007, Greg Ewing wrote:
> Collin Winter wrote:
> > Treat dates as if they have a time-part of midnight. This is my preferred
> > solution, and it is already what the datetime module does, for example,
> > when subtracting two dates.
>
> Does it really? Seems to me you can pick any ti
Collin Winter wrote:
> Treat dates as if they have a time-part of midnight. This is my preferred
> solution, and it is already what the datetime module does, for example,
> when subtracting two dates.
Does it really? Seems to me you can pick any time of day
to be the representative time and get t
Collin Winter schrieb:
> I can't say I'm well-versed in the intricacies of date/time issues,
> but what you say makes sense. This is exactly why I brought this patch
> up here : )
Oh h...! Seems like I've opened a can of worms here. I only wanted to
add some minor enhancements and now it looks lik
At 09:20 PM 3/9/2007 +, Jon Ribbens wrote:
>If you want the answer to be "the entire of that day" then you need
>to alter the datetime module so that, e.g. subtracting 2007-03-08
>from 2007-03-09 does not return "one day" as currently, but returns
>"zero days" instead (since of course there is
Robert Brewer schrieb:
> Brett Cannon wrote:
>> On 3/9/07, Collin Winter <[EMAIL PROTECTED]> wrote:
>> > On the subject of datetime enhancements, I came across an SF patch
>> > (#1673403) the other day that proposed making it possible to compare
>> > date and datetime objects...
>>
>> I personally
On 3/9/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 3/9/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > One solution that just occurred to me -- and that skirts the issue of
> > choosing an interpretation -- is that, when comparing date and
> > datetime objects, the datetime's .date() method
On 3/9/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> One solution that just occurred to me -- and that skirts the issue of
> choosing an interpretation -- is that, when comparing date and
> datetime objects, the datetime's .date() method is called and the
> result of that call is compared to the o
Brett Cannon <[EMAIL PROTECTED]> wrote:
> > Treat dates as if they have a time-part of midnight. This is my preferred
> > solution, and it is already what the datetime module does, for example,
> > when subtracting two dates.
>
> I personally like the current solution. The proposal to just assume
"\"Martin v. Löwis\"" <[EMAIL PROTECTED]> wrote:
> There are know problems comparing durations (e.g. is 30 days more
> or less than a month?). For time stamps, there is no issue. For
> calender dates, there are again problems, in particular with time
> zones.
Python durations (datetime.timedelta)
On 3/9/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On the subject of datetime enhancements, I came across an SF patch
> (#1673403) the other day that proposed making it possible to compare
> date and datetime objects. Quoting from the patch summary:
>
> """
> Comparing a date to a datetime curre
Brett Cannon wrote:
> On 3/9/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > On the subject of datetime enhancements, I came across an SF patch
> > (#1673403) the other day that proposed making it possible to compare
> > date and datetime objects...
>
> I personally like the current solution. Th
On 3/9/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On the subject of datetime enhancements, I came across an SF patch
> (#1673403) the other day that proposed making it possible to compare
> date and datetime objects. Quoting from the patch summary:
>
> """
> Comparing a date to a datetime curre
Collin Winter schrieb:
>
> Any thoughts on this?
There are know problems comparing durations (e.g. is 30 days more
or less than a month?). For time stamps, there is no issue. For
calender dates, there are again problems, in particular with time
zones.
What I don't know (because I never used it)
BJörn Lindqvist schrieb:
>> If you extend the range to 64 bits there's no problem: the first
>> should print 3250368, the second -2208988800.
>
> I think it should be a ValueError, given that the programmer is very
> likely to further use the returned timestamp to for example insert
> stuff i
Christian Heimes schrieb:
> BJörn Lindqvist schrieb:
>> I think it should be a ValueError, given that the programmer is very
>> likely to further use the returned timestamp to for example insert
>> stuff in a database. Unix timestamps are not unambiguously defined for
>> any years other than 1970 t
On the subject of datetime enhancements, I came across an SF patch
(#1673403) the other day that proposed making it possible to compare
date and datetime objects. Quoting from the patch summary:
"""
Comparing a date to a datetime currently throws an exception. This makes no
sense. In what way is:
BJörn Lindqvist schrieb:
> Then I guess datetime.fromtimestamp() also should be fixed?:
[...]
> Would be nice if datetime.fromtimestamp(dt.totimestamp()) == dt worked
> for all datetimes.
Yeah great idea but I'm not sure if I'm up to the task. I'm not that
familiar with C level date and time libra
BJörn Lindqvist schrieb:
> I think it should be a ValueError, given that the programmer is very
> likely to further use the returned timestamp to for example insert
> stuff in a database. Unix timestamps are not unambiguously defined for
> any years other than 1970 to 2038 imho.
IIRC the unix time
On 3/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/9/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> > On 3/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 3/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > > The range of datetime objects far exceeds that of the curre
On 3/9/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> On 3/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 3/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > The range of datetime objects far exceeds that of the current Unix
> > > timestamp. Given that the range of current (32-b
On 3/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > The range of datetime objects far exceeds that of the current Unix
> > timestamp. Given that the range of current (32-bit) Unix timestamps is
> > approximately 1970 to 2038, What wo
On 3/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Christian> I'm proposing some small additions to the datetime module:
>
> >>> td = timedelta(minutes=1, seconds=7, microseconds=500)
> >>> int(td)
> 67
> >>> long(td)
> 67L
> >>> float(td)
> 67.5
> >>> rou
Christian> I'm proposing some small additions to the datetime module:
>>> td = timedelta(minutes=1, seconds=7, microseconds=500)
>>> int(td)
67
>>> long(td)
67L
>>> float(td)
67.5
>>> round(td)
68.0
Casting to the number of seconds seems a bit arbitrary. W
62 matches
Mail list logo
