Improving datetime
Colin J. Williams
fn681 at ncf.ca
Fri Mar 21 10:09:39 EDT 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.
>
More information about the Python-list
mailing list