Improving datetime

[Colin J. Williams]

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