Re: [Python-Dev] datetime module enhancements

[Greg Ewing]

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 time one minute past midnight on the
1st of January 2006." That doesn't seem a very controversial
thing to believe.

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

Re: [Python-Dev] datetime module enhancements

[Jon Ribbens]

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

Re: [Python-Dev] datetime module enhancements

[Collin Winter]

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 assumptions you want,
since datetime clearly isn't the module you want.

Anyone desperate to discuss the nuances and finer points of dates and
time algebras in Python, take it to python-ideas.

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

Re: [Python-Dev] datetime module enhancements

[Jon Ribbens]

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 read the reference, but for your sake,
> here's a brief example of temporal logic that would break::
> 
> 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.
You are assuming the answer you want and then using it as an axiom.
Your justification for this assumption was the whole point of my
question, but you have again failed to answer. I don't know how much
clearer I can make this, given that I have explicitly mentioned it
several times already.

> Hope that helps,

No, it doesn't.

Seriously, please try and understand this. I get that you wish Python
datetime was the ultra-complete temporal logic module you want it to
be. Good for you. I sympathise. If it was, I would agree with you. But
it isn't. It's a simple module for dealing with calendar dates and
times, not intervals in time. 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.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Robert Brewer]

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 of that call is compared to the original
> > > date.
> > +1
> > 
> > ...and it's a decision that can be made independently
> > of how to add or subtract dates.
> 
> I don't like it. It sounds suspiciously like "when
> comparing integers and floats, discard the non-integer
> portion of the float and then compare as integers".

...which can happen quite often, depending on your domain's requirements for 
significant digits. Integers and floats are numbers, not units, so a more 
proper analogy would have been, "it sounds like when comparing feet and inches, 
divide inches by 12 and discard any remainder." Which, again, can happen quite 
often.

But even feet and inches aren't a good analogy, because people don't say, 
"six-foot-three is six feet". But they *do* say, "is it Thursday right now?" 
quite often, and expect a yes-or-no answer, not "cannot compute". A slightly 
better analogy would be armies and platoons: when you compare armies (on almost 
any scale except size), you can't say an army is more or less than a platoon in 
that same army. The platoon is (part of) the army and the army is (made of) the 
platoons. So order is important only at a given level of granularity:

  Army1 = [P1, P2, P3]
  Army2 = [Px, Py, Pz]
  sorted([Army1, Army2, P1, P2, P3, Px, Py, Pz])
  [Army1, P1, P2, P3, Px, Py, Army2, Pz]

...that is, it doesn't matter where Army2 appears, as long as it's in the 
second half of the list. Note that the platoons can still be ordered relative 
to other platoons in the same army.

Likewise, when comparing dates to date-times (but not when adding them), the 
mental model of dates and times acts more like nested sets than continuous 
functions:

  Date1 = Datetimes(1, 2, 3)
  Date2 = Datetimes(x, y, z)
  sorted([Date1, Date2, ...])
  [Date1, T1, T2, T3, Tx, Ty, Date2, Tz]

...and the above can be achieved by:

class nested_datetime(datetime):
def __cmp__(self, other):
if isinstance(other, datetime):
return datetime.__cmp__(self, other)
elif isinstance(other, date):
return cmp(self.date(), other)
raise TypeError


Robert Brewer
System Architect
Amor Ministries
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Steven Bethard]

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 in articles:
> if article.datetime_posted > cutoff_date:
> recent_articles.append(article)
> return recent_articles

Thanks for being concrete here. =)

> Would temporal interval logic make it so an article with
> datetime(2007, 1, 1, 0, 0, 0) be included, if cutoff_date was
> date(2007, 1, 1)?

No, datetime(2007, 1, 1, 0, 0, 0) is not *after* date(2007, 1, 1), it
is *included* within it.  If you want an article with that datetime to
be included, you should be comparing against datetime(2006, 12, 31,
23, 59, 59) or date(2006, 12, 31).

> What about articles with datetimes (2007, 1, 1, 0, 0, 1)

No. For the same reason as above.

> and (2007, 1, 2, 0, 0, 0) respectively?

Yes.

> I believe that "temporal interval logic" has to include at least
> the last two examples in recent_articles, otherwise it would
> be highly annoying.

Could you elaborate?  Right now, to get the results you want with your
code, you have to compare against datetime(2006, 12, 31, 23, 59, 59).
How is comparing against date(2006, 12, 31) any worse?

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[BJörn Lindqvist]

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.
>
> I really don't understand what the problem is with having a date()
> behave like a proper temporal interval.  The only person complaining
> about that interpretation acknowledged that for his purposes, it would
> be better than the status quo.  And I have yet to see a use case where
> being consistent with temporal interval logic is a problem.

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 in articles:
if article.datetime_posted > cutoff_date:
recent_articles.append(article)
return recent_articles

Would temporal interval logic make it so an article with
datetime(2007, 1, 1, 0, 0, 0) be included, if cutoff_date was
date(2007, 1, 1)? What about articles with datetimes (2007, 1, 1, 0,
0, 1) and (2007, 1, 2, 0, 0, 0) respectively? I believe that "temporal
interval logic" has to include at least the last two examples in
recent_articles, otherwise it would be highly annoying.

-- 
mvh Björn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Steven Bethard]

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

I really don't understand what the problem is with having a date()
behave like a proper temporal interval.  The only person complaining
about that interpretation acknowledged that for his purposes, it would
be better than the status quo.  And I have yet to see a use case where
being consistent with temporal interval logic is a problem.

STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Christian Heimes]

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 always smaller than the datetime for the
same day - even for midnight. The date 2007-01-02 is smaller than
2007-01-02 00:00:00 but larger than 2007-01-01 24:00:00.

>>> date(2007, 1, 2) < datetime(2007, 1, 2, 0, 0, 0)
True
>>> date(2007, 1, 2) > datetime(2007, 1, 1, 24, 0, 0)
True
>>> date(2007, 1, 2) == datetime(2007, 1, 2, 0, 0, 0)
False
>>> date(2007, 1, 2) in datetime(2007, 1, 2, 0, 0, 0)
TypeError(...)

>>> datetime(2007, 1, 2, 0, 0, 0) < date(2007, 1, 2)
TypeError(...)
>>> datetime(2007, 1, 2, 0, 0, 0) > date(2007, 1, 2)
TypeError(...)
>>> datetime(2007, 1, 2, 0, 0, 0) == date(2007, 1, 2)
False
>>> datetime(2007, 1, 2, 0, 0, 0) in date(2007, 1, 2)
True

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

Re: [Python-Dev] datetime module enhancements

[Steven Bethard]

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 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.  I still encourage you to read the
reference, but for your sake, here's a brief example of temporal logic
that would break::

We know that:
date(2006, 1, 1) *Includes* datetime(2006, 1, 1, 0, 0, 1)

And under your definition
date(2006, 1, 1) *Is Simultaneous With* datetime(2006, 1, 1, 0, 0, 0)

But that's a contradiction because
datetime(2006, 1, 1, 0, 0, 0) *Does Not Include* datetime(2006, 1,
1, 0, 0, 1)

Hope that helps,

STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Oleg Broytmann]

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 to be very useful, in a Pythonic sort of way.

   Python world has excellent mxDateTime that does a very good job of date
parsing and date/time arithmetic!

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Tony Nelson]

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.

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 to be very useful, in a Pythonic sort of way.

>From old New Inside Macintosh, _Operating System Utilities_, Ch. 4 "Date,
Time, and Measurement Utilities":

Calculating Dates
-
In the date-time record and long date-time record, any value in the month,
day, hour, minute, or second field that exceeds the maximum value allowed
for that field, will cause a wraparound to a future date and time when you
modify the date-time format.

*   In the month field, values greater than 12 cause a wraparound
to a future year and month.
*   In the day field, values greater than the number of days in a
given month cause a wraparound to a future month and day.
*   In the hour field, values greater than 23 cause a wraparound to
a future day and hour.
*   In the minute field, values greater than 59 cause a wraparound
to a future hour and minute.
*   In the seconds field, values greater than 59 cause a wraparound
to a future minute and seconds.

You can use these wraparound facts to calculate and retrieve information
about a specific date. For example, you can use a date-time record and the
DateToSeconds and SecondsToDate procedures to calculate the 300th day of
1994. Set the month field of the date-time record to 1 and the year field
to 1994. To find the 300th day of 1994, set the day field of the date-time
record to 300. Initialize the rest of the fields in the record to values
that do not exceed the maximum value allowed for that field. (Refer to the
description of the date-time record on page 4-23 for a complete list of
possible values). To force a wrap-around, first convert the date and time
(in this example, January 1, 1994) to the number of seconds elapsed since
midnight, January 1, 1904 (by calling the DateToSeconds procedure). Once
you have converted the date and time to a number of seconds, you convert
the number of seconds back to a date and time (by calling the SecondsToDate
procedure). The fields in the date-time record now contain the values that
represent the 300th day of 1994. Listing 4-6 shows an application-defined
procedure that calculates the 300th day of the Gregorian calendar year
using a date-time record.

Listing 4-6 Calculating the 300th day of the year

PROCEDURE MyCalculate300Day;
VAR
myDateTimeRec:  DateTimeRec;
mySeconds:  LongInt;
BEGIN
WITH myDateTimeRec DO
BEGIN
year := 1994;
month := 1;
day := 300;
hour := 0;
minute := 0;
second := 0;
dayOfWeek := 1;
END;
DateToSeconds (myDateTimeRec, mySeconds);
SecondsToDate (mySeconds, myDateTimeRec);
END;

The DateToSeconds procedure converts the date and time to the number of
seconds elapsed since midnight, January 1, 1904, and the SecondsToDate
procedure converts the number of seconds back to a date and time. After the
conversions, the values in the year, month, day, and dayOfWeek fields of
the myDateTimeRec record represent the year, month, day of the month, and
day of the week for the 300th day of 1994. If the values in the hour,
minute, and second fields do not exceed the maximum value allowed for each
field, the values remain the same after the conversions (in this example,
the time is exactly 12:00 A.M.).

Similarly, you can use a long date-time record and the LongDateToSeconds
and LongSecondsToDate procedures to compute the day of the week
corresponding to a given date. Listing 4-7 shows an application-defined
procedure that computes and retrieves the name of the day for July 4, 1776.
Note that because the year is prior to 1904, it is necessary to use a long
date-time record.
-- 

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

Re: [Python-Dev] datetime module enhancements

[Greg Ewing]

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

Re: [Python-Dev] datetime module enhancements

[Jon Ribbens]

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.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Christian Heimes]

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
before 1903. It looks like a bug in pytz

>>> dt = datetime(2007, 3, 11, 0, 0, 0)
>>> aj = pytz.timezone("Africa/Johannesburg")
>>> aj.utcoffset(dt)
datetime.timedelta(0, 5400)

should be 7200 seconds in 2007

 pytz.timezone('Etc/GMT+2')._utcoffset
> datetime.timedelta(-1, 79200)

That's another bug. Side note: You shouldn't access the _utcoffset
attribute. The offset may depend on the date.

I notified Stuart about the two issues in his package.

Christian

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

Re: [Python-Dev] datetime module enhancements

[Christian Heimes]

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
> 
> 
> 
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

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

Re: [Python-Dev] datetime module enhancements

[Tristan Seligmann]

* 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
> of daylight savings, which you can read more about in the Python
> Library Reference (datetime.tzinfo). Amost all (over 540) of the Olson
> timezones are supported.

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

>>> pytz.timezone('Etc/GMT+2')._utcoffset
datetime.timedelta(-1, 79200)
# I thought I asked for GMT+2, not GMT-2
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


signature.asc
Description: Digital signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Greg Ewing]

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 difference between two consecutive
integers should be 0... would you?

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

Re: [Python-Dev] datetime module enhancements

[Collin Winter]

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 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 like the improvements and
> > the datetime module have to be carefully defined and PEPed.
> >
> > I'm trying to summarize the discussed issues and proposals:
> >
> >  * Change the underlying time_t type (Unix timestamp) to use a unsigned
> > 64bit integer even on 32 bit operating systems.
> >
> >  * Carefully define the comparison between date and datetime objects.
> >
> >  * int(timedelta) and float(timedelta) returns seconds
> >
> >  * Add methods to datetime to cast from/to Julian Date Number (also MJD
> > and RJD)
> >
> >  * What about moving the C extension to _datetime so we can implement
> > some non time consuming extensions in Python?
> >
> >  * 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/
> >
> >  * The dateutil package contains additional features which may prove as
> > useful: http://labix.org/python-dateutil
>
> Here's another one for the list, trawled off SF: patch #1118748
> (http://python.org/sf/1118748). It proposes to add the ability to
> add/subtract time and timedelta objects.

And one last patch: #1100942 (http://python.org/sf/1100942), which
would add a strptime() constructor for the date and time classes.

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

Re: [Python-Dev] datetime module enhancements

[Steven Bethard]

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) < datetime(2006, 1, 1, 0, 0, 0)
> >  date(2006, 1, 1) > datetime(2006, 1, 1, 0, 0, 0)
> >  date(2006, 1, 1) == datetime(2006, 1, 1, 0, 0, 0)
>
> You need me to explain why "a < b", "a > b" and "a == b" all being
> false simultaneously is bad!?

Yes.  One of the main reasons for having having rich comparisons
(__lt__, __eq__, etc.) is to be able to handle partial orderings like
the ones we're talking about here.

> What would "a != b" return?

True.  The intervals are not Simultaneous (equal).

> What would "cmp(a, b)" return?

According to the docs [1], "The return value is negative if x  < y,
zero if x == y and strictly positive if x > y." Which means that cmp()
is undefined in this case (and should probably raise an exception).
However, the current behavior is to return 1::

>>> class C(object):
... def __lt__(self, other):
... return False
... def __gt__(self, other):
... return False
... def __eq__(self, other):
... return False
...
>>> cmp(C(), C())
1

Since I don't know too many folks that use cmp() instead of using <, >
or = directly, returning 1 is fine with me.  Anyone who has a problem
with that should take it up with the cmp() implementation.

[1] http://docs.python.org/lib/built-in-funcs.html#l2h-17

> > even though the following would be True::
> >  date(2006, 1, 1) < datetime(2006, 1, 2, 0, 0, 0)
> >  date(2006, 1, 1) > datetime(2005, 12, 31, 0, 0, 0)
>
> Actually, your suggestion would be much better than the current
> behaviour, for my uses

Good.  Well at least we're agreed on that part.

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Collin Winter]

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.
>  >
>  > 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 original
>  > date. That is,
>  >
>  > datetime_obj < date_obj
>  >
>  > is implicitly equivalent to
>  >
>  > datetime_obj.date() < date_obj
>  >
>  > Seems a ready-made use case for that method.
>
>  +1
>
>  ...and it's a decision that can be made independently
>  of how to add or subtract dates.

That's what I thought, until Steve Bethard set me straight:
http://mail.python.org/pipermail/python-dev/2007-March/071803.html

I'm going to defer to him on this.

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

Re: [Python-Dev] datetime module enhancements

[Jon Ribbens]

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

> You can draw the analogy here with integer addition::
> 
> >>> int(1) + int(.75)
> 1
> >>> int(1) + int(1.25)
> 2

You're making my point for me. An integer (in the abstract sense)
*is* the same as a float with a zero fractional part. You're agreeing
that datetime treats dates as datetimes with a midnight time part.

> However, assuming that a date() is a datetime() with a time of
> midnight will clearly break that logic.

Could you please explain how? It doesn't look to me like it breaks
anything. I think you're assuming that "date" means "the whole of
that day" - if so then why do you think that assumption is valid?

Using your suggested analogy above, if you consider "date"s to be
"ints" and "datetime"s to be "floats", then it seems to be that
everything makes sense and is logical and coherent.

> 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) < datetime(2006, 1, 1, 0, 0, 0)
>  date(2006, 1, 1) > datetime(2006, 1, 1, 0, 0, 0)
>  date(2006, 1, 1) == datetime(2006, 1, 1, 0, 0, 0)

You need me to explain why "a < b", "a > b" and "a == b" all being
false simultaneously is bad!? What would "a != b" return? What would
"cmp(a, b)" return?

> even though the following would be True::
>  date(2006, 1, 1) < datetime(2006, 1, 2, 0, 0, 0)
>  date(2006, 1, 1) > datetime(2005, 12, 31, 0, 0, 0)

Actually, your suggestion would be much better than the current
behaviour, for my uses, even though it's totally illogical.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Steven Bethard]

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(2007, 1, 1, 0, 0, 0) > datetime.date(2006, 1, 1)
> > It's *not* okay to say that a date() is less than, greater than or
> > equal to a datetime() if the year/month/day *does* match.
>
> Why not? That only makes sense if you decide that a Python 'date'
> means 'the entire of that day'. It's not at all clear that that's
> what a Python 'date' *does* mean. And, as I mentioned before, if
> you do decide that then what Python currently does when you
> subtract dates is broken.

No, as Phillip J. Eby pointed out, there's a variety of ways to define
subtraction over intervals:
(1) Distance between start1 and start2
(2) Distance between start1 and end2
(3) Distance between end1 and start2
(4) Distance between end1 and end2
Options (1) and (4) are consistent with the current implementation.
Options (2) and (3) are not.  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 just found another case where 'date's pretend to have a time-part
> of midnight - if you add a date to a timedelta. Add 23 hours to a
> date and it's unchanged - add 24 and it moves forward a day. If a
> 'date' really is 'the entire of that day', then adding a timedelta
> to it which is not an integer multiple of 1 day should either raise
> an exception, or return some 'time duration' object that doesn't
> currently exist.

You can draw the analogy here with integer addition::

>>> int(1) + int(.75)
1
>>> int(1) + int(1.25)
2

Though if I had written the datetime module, this would have raised an
exception, rather than passing silently.  But I suspect that almost no
one is adding *hours* to *dates* so I don't particularly care how it
behaves, nor do I think that some idiosyncratic behavior in a part of
the module no one uses should dictate the behavior in the rest of the
module.

> Your argument is quite correct if you're considering some fancy
> uber-complicated kitchen-sink-included all-encompassing "temporal
> logic package", but that's not what Python's datetime is, nor
> frankly is what it should be.

I'm not expecting Python's datetime module to handle any complex
temporal logic.  But boy it would be nice if it didn't *break* basic
temporal logic, and that's certainly possible with a very small bit of
effort.  However, assuming that a date() is a datetime() with a time
of midnight will clearly break that logic.

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) < datetime(2006, 1, 1, 0, 0, 0)
 date(2006, 1, 1) > datetime(2006, 1, 1, 0, 0, 0)
 date(2006, 1, 1) == datetime(2006, 1, 1, 0, 0, 0)
even though the following would be True::
 date(2006, 1, 1) < datetime(2006, 1, 2, 0, 0, 0)
 date(2006, 1, 1) > datetime(2005, 12, 31, 0, 0, 0)
?

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Jon Ribbens]

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 compared to the original
>> date.
> 
>+1
> 
>...and it's a decision that can be made independently
>of how to add or subtract dates.

I don't like it. It sounds suspiciously like "when comparing integers
and floats, discard the non-integer portion of the float and then
compare as integers".
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Robert Brewer]

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 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 original
> date. That is,
> 
> datetime_obj < date_obj
> 
> is implicitly equivalent to
> 
> datetime_obj.date() < date_obj
> 
> Seems a ready-made use case for that method.

+1

...and it's a decision that can be made independently
of how to add or subtract dates.


Robert Brewer
System Architect
Amor Ministries
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Collin Winter]

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. I only wanted to
> add some minor enhancements and now it looks like the improvements and
> the datetime module have to be carefully defined and PEPed.
>
> I'm trying to summarize the discussed issues and proposals:
>
>  * Change the underlying time_t type (Unix timestamp) to use a unsigned
> 64bit integer even on 32 bit operating systems.
>
>  * Carefully define the comparison between date and datetime objects.
>
>  * int(timedelta) and float(timedelta) returns seconds
>
>  * Add methods to datetime to cast from/to Julian Date Number (also MJD
> and RJD)
>
>  * What about moving the C extension to _datetime so we can implement
> some non time consuming extensions in Python?
>
>  * 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/
>
>  * The dateutil package contains additional features which may prove as
> useful: http://labix.org/python-dateutil

Here's another one for the list, trawled off SF: patch #1118748
(http://python.org/sf/1118748). It proposes to add the ability to
add/subtract time and timedelta objects.

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

Re: [Python-Dev] datetime module enhancements

[Jon Ribbens]

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 'throw an
exception' and 'return a datetime'. Note that in the second case you
are agreeing with me that a date means midnight at the start of that
date ;-)

Python datetime disagrees with us both. It basically says 'add the
timedelta to midnight at the start of the date, then return just
the date part of the result'.

I assume there is some reason for this surprising behaviour. But this
is another example of where datetime is taking a pragmatic approach in
an ambiguous situation - exactly as I am suggesting in the situation
of comparing a date and a datetime.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Christian Heimes]

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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Jon Ribbens]

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.
> 
> The common linguistic usage of dates in English and German:
> "On Saturday" or "On 2007-03-07" is a undefined time anytime on Saturday
> or the whole Saturday but Saturday and Sunday are a day apart. It feels
> right to me.

That doesn't help much. English is often very vague about times and
dates, but computer programs must be have a defined answer.

What do you feel "next Tuesday plus 12 hours" means? ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Christian Heimes]

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:
"On Saturday" or "On 2007-03-07" is a undefined time anytime on Saturday
or the whole Saturday but Saturday and Sunday are a day apart. It feels
right to me.

Christian

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

Re: [Python-Dev] datetime module enhancements

[Jon Ribbens]

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* okay to say that a date() is less than, greater than or
> equal to a datetime() if the year/month/day *does* match.

Why not? That only makes sense if you decide that a Python 'date'
means 'the entire of that day'. It's not at all clear that that's
what a Python 'date' *does* mean. And, as I mentioned before, if
you do decide that then what Python currently does when you
subtract dates is broken.

I just found another case where 'date's pretend to have a time-part
of midnight - if you add a date to a timedelta. Add 23 hours to a
date and it's unchanged - add 24 and it moves forward a day. If a
'date' really is 'the entire of that day', then adding a timedelta
to it which is not an integer multiple of 1 day should either raise
an exception, or return some 'time duration' object that doesn't
currently exist.

> The correct temporal relation is During, but Python doesn't have a
> During operator. During is not the same as less-than, greater-than
> or equal-to, so all of these should be False::

I think you're assuming the Python datetime module has higher goals
than it does. It doesn't have any concept of a duration in time,
not unless you couple a 'datetime' with a 'timedelta' yourself.
And 'timedelta's are restricted to periods of time that are a fixed
number of seconds - i.e. there is no way to indicate "a month"
or "a year" (although that lack is a whole different argument ;-) )

Your argument is quite correct if you're considering some fancy
uber-complicated kitchen-sink-included all-encompassing "temporal
logic package", but that's not what Python's datetime is, nor
frankly is what it should be.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Sjoerd Mullender]

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 timestamps are not unambiguously defined for
>>> any years other than 1970 to 2038 imho.
>> IIRC the unix timestamp was originally definied as *signed* int with 32bit.
> 
> "Unix" time stamps where never defined as being 32bit. That is just an
> implementation detail. time_t was defined as an int, in second since 
> 1970, and that is all what was defined. Whether or not an int is 32bits
> depends on the hardware (and the compiler); this was never part of Unix.

As I remember, the time() system call on Version 7 Unix on the (16 bit)
PDP 11 returned the time as a C long, which on that machine was 32 bits.
 I just looked at the Version 6 Unix listing, and there too, the time is
returned as a 32 bit quantity.

I also seem to remember that in the early days, there was no such thing
as an unsigned long, so the value was necessarily signed.  But I may be
misremembering this bit.

-- 
Sjoerd Mullender

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

Re: [Python-Dev] datetime module enhancements

[Jon Ribbens]

"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 returns
> >"zero days" instead (since of course there is no time between the end
> >of one day and the start of the next day).
> 
> Unless you decide that subtraction is between days' ends.  Or days' 
> beginnings.  Either suffices to produce a 1-day result in that case, and is 
> still consistent with viewing days as slices of time.

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? ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Nick Coghlan]

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 about in the Python
> Library Reference (datetime.tzinfo). Amost all (over 540) of the Olson
> timezones are supported.

This sounds like it may at least be worth a 'See also' in the datetime 
docs...

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Christian Heimes]

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 perfect
solution for the issue.

Christian

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

Re: [Python-Dev] datetime module enhancements

[Christian Heimes]

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
> contribute the code and maintain it, etc.

Nothing is wrong with the datetime's tzinfo *class*. PyTz is not an
alternative implementation of the datetime.tzinfo *class*. It's a
database containing several hundreds of datetime.tzinfo *objects* for
various time zones.

More precisely:
The tz objects in PyTz are based on datetime.tzinfo but they are
optimized for static offsets and dynamic offsets from UTC. The objects
are also optimized for size (singletons) and pickling. The package was
written by Stuart Bishop. He is a well known Python developer and known
for high quality code. The code is well written and covered by lots of
unit and doc tests.

>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 about in the Python
Library Reference (datetime.tzinfo). Amost all (over 540) of the Olson
timezones are supported.

Christian

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

Re: [Python-Dev] datetime module enhancements

[Brett Cannon]

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.sourceforge.net/
> >
> > What is wrong with datetime's tzinfo objects?
>
> There aren't any. pytz fills that gap.

I remember some discussion about why tzinfo objects were not initially
included in the stdlib.  Don't remember why they were not (may just
have been no one wanted to bother to write them).

>
> But I think, pytz has no place in the stdlib anyway, because it has
> reasonably different release cycles (every time the timezone tables
> change).

That may have been why they were left out.

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

Re: [Python-Dev] datetime module enhancements

[André Malo]

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

There aren't any. pytz fills that gap.

But I think, pytz has no place in the stdlib anyway, because it has 
reasonably different release cycles (every time the timezone tables 
change).

nd
-- 
"Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine
beiden Gefährten nicht zu zählen brauchte" -- Karl May, "Winnetou III"

Im Westen was neues: 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Brett Cannon]

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. I only wanted to
> add some minor enhancements and now it looks like the improvements and
> the datetime module have to be carefully defined and PEPed.
>
> I'm trying to summarize the discussed issues and proposals:
>
>  * Change the underlying time_t type (Unix timestamp) to use a unsigned
> 64bit integer even on 32 bit operating systems.
>
>  * Carefully define the comparison between date and datetime objects.
>
>  * int(timedelta) and float(timedelta) returns seconds
>
>  * Add methods to datetime to cast from/to Julian Date Number (also MJD
> and RJD)
>
>  * What about moving the C extension to _datetime so we can implement
> some non time consuming extensions in Python?
>

When a use-case comes up we can make the move, but we don't need to do
it pre-emptively.

>  * 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?  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
contribute the code and maintain it, etc.

>  * The dateutil package contains additional features which may prove as
> useful: http://labix.org/python-dateutil

If someone wants to port features from dateutil to datetime, that's
fine, but they just need to be worth it.

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

Re: [Python-Dev] datetime module enhancements

[Ka-Ping Yee]

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 time of day
> to be the representative time and get the same result
> when subtracting two dates, as long as you pick the same
> one for both dates. So it's not really assuming anything
> here.

It certainly gives that appearance:

>>> from datetime import datetime
>>> datetime(2007, 1, 2) - datetime(2007, 1, 1, 0, 0, 0)
datetime.timedelta(1)
>>> str(_)
'1 day, 0:00:00'

The behaviour to the end user exposes the midnight assumption,
regardless whether it's explained by saying the constructor
makes the assumption or the subtraction makes the assumption.


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

Re: [Python-Dev] datetime module enhancements

[Greg Ewing]

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 the same result
when subtracting two dates, as long as you pick the same
one for both dates. So it's not really assuming anything
here.

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

Re: [Python-Dev] datetime module enhancements

[Christian Heimes]

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 like the improvements and
the datetime module have to be carefully defined and PEPed.

I'm trying to summarize the discussed issues and proposals:

 * Change the underlying time_t type (Unix timestamp) to use a unsigned
64bit integer even on 32 bit operating systems.

 * Carefully define the comparison between date and datetime objects.

 * int(timedelta) and float(timedelta) returns seconds

 * Add methods to datetime to cast from/to Julian Date Number (also MJD
and RJD)

 * What about moving the C extension to _datetime so we can implement
some non time consuming extensions in Python?

 * 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/

 * The dateutil package contains additional features which may prove as
useful: http://labix.org/python-dateutil

Christian

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

Re: [Python-Dev] datetime module enhancements

[Phillip J. Eby]

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 no time between the end
>of one day and the start of the next day).

Unless you decide that subtraction is between days' ends.  Or days' 
beginnings.  Either suffices to produce a 1-day result in that case, and is 
still consistent with viewing days as slices of time.

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

Re: [Python-Dev] datetime module enhancements

[Georg Brandl]

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 like the current solution.  The proposal to just assume
>> midnight goes against EIBTI in my mind.
> 
> Yeah, but the current solution goes against, um, APBP*. Not in my mind,
> but in my code. Repeatedly. I can't count how many times I've written
> code like:
> 
> if created > fdate:
> 
> when I "should" have written:
> 
> if isinstance(created, datetime.date):
> date_version_of_created = created
> else:
> date_version_of_created = created.date()
> if date_version_of_created > fdate:
> 
> But it gets better, because:
> 
> >>> isinstance(datetime.datetime(x, y, z), datetime.date)
> True
> 
> So the above won't work, you must remember to reverse the if/else:
> 
> if isinstance(created, datetime.datetime):
> date_version_of_created = created.date()
> else:
> date_version_of_created = created
> if date_version_of_created > fdate:

Why not just give date objects a date() method that returns self?
That way you can write

if created.date() > fdate:

Georg

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

Re: [Python-Dev] datetime module enhancements

[Collin Winter]

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 is called and the
> > result of that call is compared to the original date. That is,
> >
> > datetime_obj < date_obj
> >
> > is implicitly equivalent to
> >
> > datetime_obj.date() < date_obj
>
> 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* okay to say that a date() is less than, greater than or
> equal to a datetime() if the year/month/day *does* match.  The correct
> temporal relation is During, but Python doesn't have a During
> operator. During is not the same as less-than, greater-than or
> equal-to, so all of these should be False::
> datetime.datetime(2006, 1, 1, 0, 0, 0)  < datetime.date(2006, 1, 1)
> datetime.datetime(2006, 1, 1, 0, 0, 0)  > datetime.date(2006, 1, 1)
> datetime.datetime(2006, 1, 1, 0, 0, 0)  == datetime.date(2006, 1, 1)
> That is, the datetime() is not less than, greater than or equal to the
> corresponding date().
>
> Some discussion of these kinds of issues is here:
> http://citeseer.ist.psu.edu/allen94actions.html
> The essence is that in order to properly compare intervals, you need
> the Meets, Overlaps, Starts, During and Finishes operators in addition
> to the Before (<) and Simulaneous (=) operators.
>
> So, let's not conflate Before, After or Simultaneous with the other
> relations -- if it's not strictly Before (<), After (>) or
> Simultaneous (=), we can just say so by returning False.
>
> (I believe these semantics would be just fine for both of the examples
> offered so far, but let me know if you think that's not true.)

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

Thanks,
Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Steven Bethard]

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 original date. That is,
>
> datetime_obj < date_obj
>
> is implicitly equivalent to
>
> datetime_obj.date() < date_obj

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* okay to say that a date() is less than, greater than or
equal to a datetime() if the year/month/day *does* match.  The correct
temporal relation is During, but Python doesn't have a During
operator. During is not the same as less-than, greater-than or
equal-to, so all of these should be False::
datetime.datetime(2006, 1, 1, 0, 0, 0)  < datetime.date(2006, 1, 1)
datetime.datetime(2006, 1, 1, 0, 0, 0)  > datetime.date(2006, 1, 1)
datetime.datetime(2006, 1, 1, 0, 0, 0)  == datetime.date(2006, 1, 1)
That is, the datetime() is not less than, greater than or equal to the
corresponding date().

Some discussion of these kinds of issues is here:
http://citeseer.ist.psu.edu/allen94actions.html
The essence is that in order to properly compare intervals, you need
the Meets, Overlaps, Starts, During and Finishes operators in addition
to the Before (<) and Simulaneous (=) operators.

So, let's not conflate Before, After or Simultaneous with the other
relations -- if it's not strictly Before (<), After (>) or
Simultaneous (=), we can just say so by returning False.

(I believe these semantics would be just fine for both of the examples
offered so far, but let me know if you think that's not true.)

STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Jon Ribbens]

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
> midnight goes against EIBTI in my mind.

Not in mine. The comparison of a date with a datetime throwing
an exception is astonishing in my mind.

The problem is, if you don't define a 'date' as I suggest (i.e.
midnight at the start of the day in question), then what *does*
a 'date' represent?

If you want the answer to be "an unknown time on that day" then
you need to alter the datetime module so that subtracting one
date from another throws an exception.

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 no time between the end
of one day and the start of the next day).

Obviously both of those alternatives are ludicrous (not to mention
they would break backwards-compatibility), so I would suggest the
only logical solution is to make the change I proposed ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Jon Ribbens]

"\"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) do not support the concept of
"months", so that's not an issue. The timedelta type only supports
durations that are a fixed number of seconds.

I don't see what the issue with time zones would be? Surely you just
convert to the same time zone and then compare?

> What I don't know (because I never used it) is whether the datetime
> module implements time stamps. If it does (i.e. no durations,
> no time zones, no issues with leap seconds), then supporting a
> total order seems reasonable.

It supports converting *from* timestamps, but not *to* timestamps,
which is the subject of a feature request I submitted the other day
(1673409) ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Collin Winter]

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 currently throws an exception. This makes no
> sense. In what way is:
>
> datetime(2006, 1, 1, 0, 0, 0) < date(2007, 1, 1)
>
> not a perfectly reasonable and well-defined comparison? Throwing an
> exception here violates the "Principle of Least Surprise" to a considerable
> degree.
>
> Obviously some slight ambiguity arises if the date and the datetime differ
> only in the time part. There are two sensible responses in this situation
> that I can see:
>
> 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.
>
> Treat dates as if they refer to the entire day, i.e. if the date and
> datetime differ only in the time part then they are equal. This is
> consistent but becomes confusing in other situations such as when
> subtracting dates.
> """
>
> Any thoughts on this?

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 original date. That is,

datetime_obj < date_obj

is implicitly equivalent to

datetime_obj.date() < date_obj

Seems a ready-made use case for that method.

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

Re: [Python-Dev] datetime module enhancements

[Robert Brewer]

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.  The proposal to just assume
> midnight goes against EIBTI in my mind.

Yeah, but the current solution goes against, um, APBP*. Not in my mind,
but in my code. Repeatedly. I can't count how many times I've written
code like:

if created > fdate:

when I "should" have written:

if isinstance(created, datetime.date):
date_version_of_created = created
else:
date_version_of_created = created.date()
if date_version_of_created > fdate:

But it gets better, because:

>>> isinstance(datetime.datetime(x, y, z), datetime.date)
True

So the above won't work, you must remember to reverse the if/else:

if isinstance(created, datetime.datetime):
date_version_of_created = created.date()
else:
date_version_of_created = created
if date_version_of_created > fdate:

That's at least one too many "must remembers" for dumb (and busy!) ol'
me. EIBTI until it's a PITA.

Is an implicit time of 0 really so surprising? It doesn't seem to be
surprising for the datetime constructor:

>>> datetime.datetime(2007, 3, 9)
datetime.datetime(2007, 3, 9, 0, 0)

Why should it be surprising for comparisons?


Robert Brewer
System Architect
Amor Ministries
[EMAIL PROTECTED]

* APBP = "Although, practicality beats purity"
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Brett Cannon]

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 currently throws an exception. This makes no
> sense. In what way is:
>
> datetime(2006, 1, 1, 0, 0, 0) < date(2007, 1, 1)
>
> not a perfectly reasonable and well-defined comparison? Throwing an
> exception here violates the "Principle of Least Surprise" to a considerable
> degree.
>
> Obviously some slight ambiguity arises if the date and the datetime differ
> only in the time part. There are two sensible responses in this situation
> that I can see:
>
> 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.
>
> Treat dates as if they refer to the entire day, i.e. if the date and
> datetime differ only in the time part then they are equal. This is
> consistent but becomes confusing in other situations such as when
> subtracting dates.
> """
>
> Any thoughts on this?
>

I personally like the current solution.  The proposal to just assume
midnight goes against EIBTI in my mind.

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

Re: [Python-Dev] datetime module enhancements

[Martin v. Löwis]

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) is whether the datetime
module implements time stamps. If it does (i.e. no durations,
no time zones, no issues with leap seconds), then supporting a
total order seems reasonable.

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

Re: [Python-Dev] datetime module enhancements

[Martin v. Löwis]

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 in a database. 

Then this operation (the insertion into a database) should give a
ValueError. Python conceptually has only a single integer type, and
that has no range limitation.

Of course, if "conversion to time_t" was an operation in datetime,
than this should limit it in the range of time_t (which may or
may not have 32 bits).

> Unix timestamps are not unambiguously defined for
> any years other than 1970 to 2038 imho.

As others have said: this is simply not true. It depends on
the hardware, Unix explicitly, deliberately, leaves that open
to the specific operating system implementation. On a 36-bit
hardware, the range will be different.

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

Re: [Python-Dev] datetime module enhancements

[Martin v. Löwis]

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 to 2038 imho.
> 
> IIRC the unix timestamp was originally definied as *signed* int with 32bit.

"Unix" time stamps where never defined as being 32bit. That is just an
implementation detail. time_t was defined as an int, in second since 
1970, and that is all what was defined. Whether or not an int is 32bits
depends on the hardware (and the compiler); this was never part of Unix.

Regards,
Martin

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

Re: [Python-Dev] datetime module enhancements

[Collin Winter]

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:

datetime(2006, 1, 1, 0, 0, 0) < date(2007, 1, 1)

not a perfectly reasonable and well-defined comparison? Throwing an
exception here violates the "Principle of Least Surprise" to a considerable
degree.

Obviously some slight ambiguity arises if the date and the datetime differ
only in the time part. There are two sensible responses in this situation
that I can see:

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.

Treat dates as if they refer to the entire day, i.e. if the date and
datetime differ only in the time part then they are equal. This is
consistent but becomes confusing in other situations such as when
subtracting dates.
"""

Any thoughts on this?

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

Re: [Python-Dev] datetime module enhancements

[Christian Heimes]

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

Christian

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

Re: [Python-Dev] datetime module enhancements

[Christian Heimes]

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 timestamp was originally definied as *signed* int with 32bit.

http://en.wikipedia.org/wiki/Time_t
---
Unix and POSIX-compliant systems implement the time_t type as a signed
integer (typically 32 or 64 bits wide) which represents the number of
seconds since the start of the Unix epoch: midnight UTC of January 1,
1970 (not counting leap seconds). Some systems support negative time
values, while others do not.
---

But you made a good point! What do you think about
datetime.totimestamp(asLong=False)? The method would raise a ValueError
or OverflowError if the value is > sys.maxint or < -(sys.maxint-1).

Christian

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

Re: [Python-Dev] datetime module enhancements

[BJörn Lindqvist]

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 current Unix
> > > > timestamp.  Given that the range of current (32-bit) Unix timestamps is
> > > > approximately 1970 to 2038, What would the output of this be?
> > > >
> > > > dt = datetime.datetime(3000, 1, 1, 0, 0, 0)
> > > > print dt.totimestamp()
> > > > dt = datetime.datetime(1900, 1, 1, 0, 0, 0)
> > > > print dt.totimestamp()
> > >
> > > 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 in a database. Unix timestamps are not unambiguously defined for
> > any years other than 1970 to 2038 imho.
>
> But they will be. And they already are on some platforms. The database
> should raise an OverflowError if a timestamp is out of range, but it
> would be unpythonic to limit those outcomes to 32 bits.

Then I guess datetime.fromtimestamp() also should be fixed?:

>>> datetime.fromtimestamp(-1)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: timestamp out of range for platform localtime()/gmtime() function
>>> datetime.fromtimestamp(-0.5)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: microsecond must be in 0..99
>>> datetime.fromtimestamp(99)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: timestamp out of range for platform time_t

Would be nice if datetime.fromtimestamp(dt.totimestamp()) == dt worked
for all datetimes.

-- 
mvh Björn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Guido van Rossum]

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-bit) Unix timestamps is
> > > approximately 1970 to 2038, What would the output of this be?
> > >
> > > dt = datetime.datetime(3000, 1, 1, 0, 0, 0)
> > > print dt.totimestamp()
> > > dt = datetime.datetime(1900, 1, 1, 0, 0, 0)
> > > print dt.totimestamp()
> >
> > 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 in a database. Unix timestamps are not unambiguously defined for
> any years other than 1970 to 2038 imho.

But they will be. And they already are on some platforms. The database
should raise an OverflowError if a timestamp is out of range, but it
would be unpythonic to limit those outcomes to 32 bits.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[BJörn Lindqvist]

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 would the output of this be?
> >
> > dt = datetime.datetime(3000, 1, 1, 0, 0, 0)
> > print dt.totimestamp()
> > dt = datetime.datetime(1900, 1, 1, 0, 0, 0)
> > print dt.totimestamp()
>
> 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 in a database. Unix timestamps are not unambiguously defined for
any years other than 1970 to 2038 imho.

-- 
mvh Björn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[Guido van Rossum]

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
> >>> round(td)
> 68.0
>
> Casting to the number of seconds seems a bit arbitrary.  Why not cast to the
> number of days or number of microseconds?

Because seconds are what's used everywhere else when Python represents
time as a number (time.time(), time.sleep(), select, socket timeout,
etc.)

> If you allow interpretation of
> timedeltas as int, long or float I'd argue that round not be included.
> Instead, just round the output of float.
>
> Christian> datetime.datetime has a method (class factory)
> Christian> fromtimestamp() but its instances are missing a totimestamp()
> Christian> method that return the Unix timestamp for a date (seconds
> Christian> since 1970-01-01 00:00:00 UTC).
>
> 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 would the output of this be?
>
> dt = datetime.datetime(3000, 1, 1, 0, 0, 0)
> print dt.totimestamp()
> dt = datetime.datetime(1900, 1, 1, 0, 0, 0)
> print dt.totimestamp()

If you extend the range to 64 bits there's no problem: the first
should print 3250368, the second -2208988800.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime module enhancements

[skip]

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.  Why not cast to the
number of days or number of microseconds?  If you allow interpretation of
timedeltas as int, long or float I'd argue that round not be included.
Instead, just round the output of float.

Christian> datetime.datetime has a method (class factory)
Christian> fromtimestamp() but its instances are missing a totimestamp()
Christian> method that return the Unix timestamp for a date (seconds
Christian> since 1970-01-01 00:00:00 UTC).

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 would the output of this be?

dt = datetime.datetime(3000, 1, 1, 0, 0, 0)
print dt.totimestamp()
dt = datetime.datetime(1900, 1, 1, 0, 0, 0)
print dt.totimestamp()

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

[Python-Dev] datetime module enhancements

[Christian Heimes]

Hello!

This is my first posting to the Python developer list so please forgive
me if I'm doing something wrong.

In the past few weeks I've worked a lot with dates and times. I found
several small annoyances in the datetime module. For example there was
no obvious way to cast a timedelta to an int or float. 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

datetime.datetime has a method (class factory) fromtimestamp() but its
instances are missing a totimestamp() method that return the Unix
timestamp for a date (seconds since 1970-01-01 00:00:00 UTC).

Some people might miss a from and to julian day number (JDN) and
modified julian day (MJD) converter in datetime.date and
datetime.datetime. MJD is used as base in VMS and JDN, MJD and RJD are
used by astronomers. It's also very useful when one has to deal with
dates before 0 and converting dates between foreign calendars.

>From http://www.slac.stanford.edu/~rkj/crazytime.txt
---
November 17, 1858 is the base of the Modified Julian Day system.

The original Julian Day (JD) is used by astronomers and expressed in
days since noon January 1, 4713 B.C.  This measure of time was
introduced by Joseph Scaliger in the 16th century.  It is named in
honor of his father, Julius Caesar Scaliger (note that this Julian Day
is different from the Julian calendar named for the Roman Emperor
Julius Caesar!).
---

http://en.wikipedia.org/wiki/Julian_Day

I'm willing to implement the features myself but I need a mentor who
helps me to correct my code and applies it to the Python svn repository.

A patch for timedelta is already available at
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1665292&group_id=5470

Comments?

Christian

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