Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: Improving datetime

Reply
Thread Tools

Re: Improving datetime

 
 
Nicholas F. Fabry
Guest
Posts: n/a
 
      03-19-2008
On Mar 19, 2008, at 16:30, Christian Heimes wrote:

> Nicholas F. Fabry schrieb:
>> This is a query for information as to how to proceed. I am not a
>> professional programmer, but I use Python a great deal to help me
>> in my main job, which involves designing schedules for a global
>> airline. As such, I use datetime (and dateutil) extensively, and
>> after much use, I have come to some conclusions about their
>> utility, and how to improve them. Some of these changes are quite
>> minor and would result in a large increase in utility (low hanging
>> fruit), while some changes are major, and would result in less
>> obvious benefits - but these changes would increase the 'Python
>> Zen' of them.
>> So - where should I propose these changes? Here? python-dev?
>> Should I write up a full PEP or should I just give a more informal
>> outline with code samples? I would volunteer to help maintain/
>> improve datetime, but I don't speak C at all, unfortunately, and
>> datetime appears to be in C.

>
> Please write a detailed but not too long proposal to the Python
> ideas mailing list. The proposal should explain how you like to
> improve the datetime module. But *please* don't write a novel.
> You'll get more attention when the signal to noise ratio is high. A
> bullet list of features is easier to read than a long text block.
>


Thank you for the prompt response and suggestion! I am writing up a
proposal presently. There are, however, two broad category of changes
- the 'easy' changes, which could be accomplished with little
additional effort, and the 'hard' changes, which would require
significant reworking of the datetime class (or a wrapper around it).
I was going to break my proposal up into two parts, the easy part and
the hard part. Does that sound like a good idea? Or should I unify
the two? The prime purpose of all the changes, easy and hard, is to
make timezone handling accurate and clear, reduce and make clearer the
(application programmer) code required to use them, and give more
informaton to the programmer about errors, not silently assume
something and pass them.

I have to sign up for that mailing list - I will do so, and submit my
ideas there.

Please clarify how long a novel is? The problem with the modules are
not bugs, they are problems with real world use scenarios that result
in inescabably ugly code without improvements to the module - so the
explanations involve code samples and use cases... so they may be
'long'. Could you suggest a maximum number of (70 char) lines, or an
example of an overly long proposal?


> I'm a core developer and I may be interested in mentoring your
> proposal. I can guide you through the process, review code and
> commit it.
>


Thank you very much for the offer - I greatly appreciate it. I must
admit, my motivation is because Python made programming so much fun
for me again (my first machine was a Sinclair ZX80, long, long ago),
and I want to improve this part of the language so datetime
calculations are clean and neat (like the rest of Python) and don't
force programmers to manually go through what the library should do
for them.


> Yes, the datetime module is written in C. But we may move the C code
> to _datetime and create a facade module in Python.
>


That would be excellent for me, because the underlying datetime
routines work correctly and quickly; it's the 'topmost' layer that
needs to be improved to do the right thing. And, I could then
actually write/maintain the Python code in the facade module, rather
than request someone else 'do it for me' in C.

To summarize my proposal VERY briefly:


- Make aware datetime objects display in local time, but calculate/
compare in UTC.

- Raise exceptions when an illegal or ambiguous datetime is instantated.


Thank you again,

Nick






> Christian


 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      03-19-2008
On Wed, 19 Mar 2008 17:40:39 -0400, Nicholas F. Fabry wrote:

> To summarize my proposal VERY briefly:
>
>
> - Make aware datetime objects display in local time, but calculate/
> compare in UTC.


Your proposal is ambiguous. What does that mean? Can you give an example?




> - Raise exceptions when an illegal or ambiguous datetime is instantated.


You mean like they already do?

>>> datetime.datetime(2008, 03, 35) # 35th of March

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: day is out of range for month




As for ambiguous, how can datetime arguments be ambiguous?

Help on class datetime in module datetime:

class datetime(date)
| datetime(year, month, day[, hour[, minute[, second[,
microsecond[,tzinfo]]]]])


What possible ambiguity is there?


--
Steven
 
Reply With Quote
 
 
 
 
castironpi@gmail.com
Guest
Posts: n/a
 
      03-21-2008
On Mar 19, 5:32*pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:
> On Wed, 19 Mar 2008 17:40:39 -0400, Nicholas F. Fabry wrote:
> > To summarize my proposal VERY briefly:

>
> > - Make aware datetime objects display in local time, but calculate/
> > compare in UTC.

>
> What possible ambiguity is there?


I agree.

>>> D.datetime( 2008, 3, 23 )

datetime.datetime(2008, 3, 23, 0, 0)
>>> a=_
>>> D.timedelta( minutes= 30, seconds= 80 )

datetime.timedelta(0, 1880)
>>> b= _
>>> a+b

datetime.datetime(2008, 3, 23, 0, 31, 20)
>>> a+b-a

datetime.timedelta(0, 1880)


 
Reply With Quote
 
Colin J. Williams
Guest
Posts: n/a
 
      03-21-2008
Nicholas F. Fabry wrote:
> On Mar 19, 2008, at 16:30, Christian Heimes wrote:
>
>> Nicholas F. Fabry schrieb:
>>> This is a query for information as to how to proceed. I am not a
>>> professional programmer, but I use Python a great deal to help me in
>>> my main job, which involves designing schedules for a global
>>> airline. As such, I use datetime (and dateutil) extensively, and
>>> after much use, I have come to some conclusions about their utility,
>>> and how to improve them. Some of these changes are quite minor and
>>> would result in a large increase in utility (low hanging fruit),
>>> while some changes are major, and would result in less obvious
>>> benefits - but these changes would increase the 'Python Zen' of them.
>>> So - where should I propose these changes? Here? python-dev?
>>> Should I write up a full PEP or should I just give a more informal
>>> outline with code samples? I would volunteer to help
>>> maintain/improve datetime, but I don't speak C at all,
>>> unfortunately, and datetime appears to be in C.

>>
>> Please write a detailed but not too long proposal to the Python ideas
>> mailing list. The proposal should explain how you like to improve the
>> datetime module. But *please* don't write a novel. You'll get more
>> attention when the signal to noise ratio is high. A bullet list of
>> features is easier to read than a long text block.
>>

>
> Thank you for the prompt response and suggestion! I am writing up a
> proposal presently. There are, however, two broad category of changes -
> the 'easy' changes, which could be accomplished with little additional
> effort, and the 'hard' changes, which would require significant
> reworking of the datetime class (or a wrapper around it). I was going
> to break my proposal up into two parts, the easy part and the hard
> part. Does that sound like a good idea? Or should I unify the two?
> The prime purpose of all the changes, easy and hard, is to make timezone
> handling accurate and clear, reduce and make clearer the (application
> programmer) code required to use them, and give more informaton to the
> programmer about errors, not silently assume something and pass them.
>
> I have to sign up for that mailing list - I will do so, and submit my
> ideas there.
>
> Please clarify how long a novel is? The problem with the modules are
> not bugs, they are problems with real world use scenarios that result in
> inescabably ugly code without improvements to the module - so the
> explanations involve code samples and use cases... so they may be
> 'long'. Could you suggest a maximum number of (70 char) lines, or an
> example of an overly long proposal?
>
>
>> I'm a core developer and I may be interested in mentoring your
>> proposal. I can guide you through the process, review code and commit it.
>>

>
> Thank you very much for the offer - I greatly appreciate it. I must
> admit, my motivation is because Python made programming so much fun for
> me again (my first machine was a Sinclair ZX80, long, long ago), and I
> want to improve this part of the language so datetime calculations are
> clean and neat (like the rest of Python) and don't force programmers to
> manually go through what the library should do for them.
>
>
>> Yes, the datetime module is written in C. But we may move the C code
>> to _datetime and create a facade module in Python.
>>

>
> That would be excellent for me, because the underlying datetime routines
> work correctly and quickly; it's the 'topmost' layer that needs to be
> improved to do the right thing. And, I could then actually
> write/maintain the Python code in the facade module, rather than request
> someone else 'do it for me' in C.
>
> To summarize my proposal VERY briefly:
>
>
> - Make aware datetime objects display in local time, but
> calculate/compare in UTC.
>
> - Raise exceptions when an illegal or ambiguous datetime is instantated.
>
>
> Thank you again,
>
> Nick
>
>
>
>
>
>
>> Christian

Nick,

You might consider adding the Julian
date
(http://en.wikipedia.org/wiki/Julian_date).

I had a crack at this a while ago but
didn't seem to get quire the right
result, using the ACM algorithm. I
seemed to be a day out at the BC/AD divide.

Colin W.
>

 
Reply With Quote
 
Colin J. Williams
Guest
Posts: n/a
 
      03-21-2008
Nicholas F. Fabry wrote:
> On Mar 19, 2008, at 16:30, Christian Heimes wrote:
>
>> Nicholas F. Fabry schrieb:
>>> This is a query for information as to how to proceed. I am not a
>>> professional programmer, but I use Python a great deal to help me in
>>> my main job, which involves designing schedules for a global
>>> airline. As such, I use datetime (and dateutil) extensively, and
>>> after much use, I have come to some conclusions about their utility,
>>> and how to improve them. Some of these changes are quite minor and
>>> would result in a large increase in utility (low hanging fruit),
>>> while some changes are major, and would result in less obvious
>>> benefits - but these changes would increase the 'Python Zen' of them.
>>> So - where should I propose these changes? Here? python-dev?
>>> Should I write up a full PEP or should I just give a more informal
>>> outline with code samples? I would volunteer to help
>>> maintain/improve datetime, but I don't speak C at all,
>>> unfortunately, and datetime appears to be in C.

>>
>> Please write a detailed but not too long proposal to the Python ideas
>> mailing list. The proposal should explain how you like to improve the
>> datetime module. But *please* don't write a novel. You'll get more
>> attention when the signal to noise ratio is high. A bullet list of
>> features is easier to read than a long text block.
>>

>
> Thank you for the prompt response and suggestion! I am writing up a
> proposal presently. There are, however, two broad category of changes -
> the 'easy' changes, which could be accomplished with little additional
> effort, and the 'hard' changes, which would require significant
> reworking of the datetime class (or a wrapper around it). I was going
> to break my proposal up into two parts, the easy part and the hard
> part. Does that sound like a good idea? Or should I unify the two?
> The prime purpose of all the changes, easy and hard, is to make timezone
> handling accurate and clear, reduce and make clearer the (application
> programmer) code required to use them, and give more informaton to the
> programmer about errors, not silently assume something and pass them.
>
> I have to sign up for that mailing list - I will do so, and submit my
> ideas there.
>
> Please clarify how long a novel is? The problem with the modules are
> not bugs, they are problems with real world use scenarios that result in
> inescabably ugly code without improvements to the module - so the
> explanations involve code samples and use cases... so they may be
> 'long'. Could you suggest a maximum number of (70 char) lines, or an
> example of an overly long proposal?
>
>
>> I'm a core developer and I may be interested in mentoring your
>> proposal. I can guide you through the process, review code and commit it.
>>

>
> Thank you very much for the offer - I greatly appreciate it. I must
> admit, my motivation is because Python made programming so much fun for
> me again (my first machine was a Sinclair ZX80, long, long ago), and I
> want to improve this part of the language so datetime calculations are
> clean and neat (like the rest of Python) and don't force programmers to
> manually go through what the library should do for them.
>
>
>> Yes, the datetime module is written in C. But we may move the C code
>> to _datetime and create a facade module in Python.
>>

>
> That would be excellent for me, because the underlying datetime routines
> work correctly and quickly; it's the 'topmost' layer that needs to be
> improved to do the right thing. And, I could then actually
> write/maintain the Python code in the facade module, rather than request
> someone else 'do it for me' in C.
>
> To summarize my proposal VERY briefly:
>
>
> - Make aware datetime objects display in local time, but
> calculate/compare in UTC.
>
> - Raise exceptions when an illegal or ambiguous datetime is instantated.
>
>
> Thank you again,
>
> Nick
>
>
>
>
>
>
>> Christian

Nick,

You might consider adding the Julian
date
(http://en.wikipedia.org/wiki/Julian_date).

I had a crack at this a while ago but
didn't seem to get quire the right
result, using the ACM algorithm. I
seemed to be a day out at the BC/AD divide.

Colin W.
>

 
Reply With Quote
 
Aahz
Guest
Posts: n/a
 
      03-21-2008
In article <(E-Mail Removed)>,
Nicholas F. Fabry <(E-Mail Removed)> wrote:
>
>Please clarify how long a novel is? The problem with the modules are
>not bugs, they are problems with real world use scenarios that result
>in inescabably ugly code without improvements to the module - so the
>explanations involve code samples and use cases... so they may be
>'long'. Could you suggest a maximum number of (70 char) lines, or an
>example of an overly long proposal?


I'd suggest starting with a simple example of a problem you see. You may
well be up against a design constraint: the datetime module is intended
to provide *simple* and reasonably robust handling. There doesn't seem
to be a PEP, unfortunately, but you might want to look for the discussion
history leading to the including of datetime.
--
Aahz ((E-Mail Removed)) <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan
 
Reply With Quote
 
Christian Heimes
Guest
Posts: n/a
 
      03-21-2008
Colin J. Williams schrieb:
> You might consider adding the Julian date
> (http://en.wikipedia.org/wiki/Julian_date).
>
> I had a crack at this a while ago but didn't seem to get quire the right
> result, using the ACM algorithm. I seemed to be a day out at the BC/AD
> divide.


Yes, the Julian date family is very useful when dealing with dates
before 1900. I'm +1 for adding JDT and MJD.

TAI64 is another time format used for high precision and real time
measurement. http://cr.yp.to/libtai/tai64.html

Christian

 
Reply With Quote
 
Nicholas F. Fabry
Guest
Posts: n/a
 
      03-22-2008

On Mar 21, 2008, at 13:36, Christian Heimes wrote:

> Colin J. Williams schrieb:
>> You might consider adding the Julian date
>> (http://en.wikipedia.org/wiki/Julian_date).
>>
>> I had a crack at this a while ago but didn't seem to get quire the
>> right
>> result, using the ACM algorithm. I seemed to be a day out at the
>> BC/AD
>> divide.

>
> Yes, the Julian date family is very useful when dealing with dates
> before 1900. I'm +1 for adding JDT and MJD.
>
> TAI64 is another time format used for high precision and real time
> measurement. http://cr.yp.to/libtai/tai64.html
>


This is that 'feature creep' thing I keep reading about on Dilbert,
eh?

Obviously, this would not be considered an 'easy bit' - however, the
basic datetime.datetime class needs overhauling anyway when we get to
the harder bits. So, it's worth determining whether we just want to
have it run in the proleptic Gregorian calendar (ISO 8601), or figure
out other calendars as well. I don't know anything about TAI64, but
I'll read about it. The Julian I do know about (rioting after
'losing' 10 days? Sheesh!) - it was a pretty reasonable swag at
hitting the solar year for its time....


<wild speculations>
Perhaps it might be wise to consider a 'calendar definition object' -
I'll dub it a calinfo object for now - that allows third parties to
develop a set of rules that define a) how to count in a calendar, and
b) how to translate unambiguously from one calendar to another. This
suggests that we need a 'standard' calendar, much like UTC is the
default timezone for calculations; the proleptic Gregorian seems like
the obvious choice for now.

So, a new 'superaware' datetime object represents a moment in time and
would have:

a local datetime, representing what 'local' clocks and calendar
indicate at that time
a UTC datetime, representing what UTC clocks and calendar indicate at
that time
a tzinfo object, encapsulating the the rules for translating local
times to/from UTC, and
a calinfo object, encapsulating:
the calculation rules for adding & subtracting timedeltas to datetimes
the calculation rules for finding the timedelta between two datetimes
the translation rules for converting a datetime with a calinfo object
into a datetime with a 'standard' calinfo object

With time zones, because their offsets regularly swing back and forth,
we have issues with illegal and ambiguous local times. I don't know
much about different calendars - I am somewhat sure for Gregorian <-->
Julian there are no ambiguities or 'illegal' dates, but I don't know
about other calendars.

I haven't thought of this before. I need to mull over how to do this
- if we are going to spend the time developing three different methods
of calculations for three different calendars, and I know there are
other calendar systems in the world, it strikes me that the forward
thinking thing to do is figure out how to abstract the calendar rule
concept, develop a few common examples, and leave it to others
(initially) to develop other calendars, much as third parties
implemented concrete tzinfo subclasses. In doing so, they revealed
some of the present limitations with the current implementation of
datetime, that we are now considering updating. We may not have
enough experience here of other calendar systems to get this totally
right on the first go round, but it sounds worth a try....
</wild speculations>


> Christian
>


P.S. By Stewart, I assume you mean the author of pytz? And I think I
got the 'no novel' concept - write for people who understand the basic
ideas already. Have a good weekend!

Nick







> --
> http://mail.python.org/mailman/listinfo/python-list


 
Reply With Quote
 
John Machin
Guest
Posts: n/a
 
      03-22-2008
On Mar 22, 4:36 am, Christian Heimes <(E-Mail Removed)> wrote:
> Colin J. Williams schrieb:
>
> > You might consider adding the Julian date
> > (http://en.wikipedia.org/wiki/Julian_date).

>
> > I had a crack at this a while ago but didn't seem to get quire the right
> > result, using the ACM algorithm. I seemed to be a day out at the BC/AD
> > divide.


1. Somewhere in the Colin-Christian-Nicholas thread, the "Julian date"
and the "Julian calendar" seem to become conflated.
2. "day out": possibly because there is no year 0; year 1 BCE is
followed immediately by year 1 CE.

>
> Yes, the Julian date family is very useful when dealing with dates
> before 1900.


I'm having some difficulty understanding the above sentence, given
either interpretation of "Julian date family". What is the
significance of 1900?

[Julian calendar interpretation] Some countries (including Russia,
China, Greece and Turkey) did not adopt the Gregorian calendar until
after 1900. Dealing with a date expressed as (year, month, day) is far
from easy for approx year range 1582 to 1926 unless it has been
expressly tagged as e.g. "old style" or "new style". If so tagged,
there is to me no difference in ease of use between the proleptic
Julian calendar and the proleptic Gregorian calendar.

[Julian date as used in astronomy] This supports dates back to about
4800 BCE easily, whereas Python's datetime module supports the
proleptic Gregorian calendar only back to year 1 CE.

Cheers,
John
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: [2.4.4] creating a datetime.datetime from an XML xs:dateTime skip@pobox.com Python 2 01-06-2009 01:31 PM
[2.4.4] creating a datetime.datetime from an XML xs:dateTime Martin Python 0 12-27-2008 08:08 PM
mx.DateTime to datetime.datetime mp Python 1 07-28-2006 10:57 PM
datetime: .datetime-.datetime = .timedelta, .time-.time=TypeError ? Christos TZOTZIOY Georgiou Python 3 09-13-2003 10:44 AM
RE: datetime: .datetime-.datetime = .timedelta, .time-.time=TypeError ? Tim Peters Python 0 09-09-2003 12:57 AM



Advertisments