Improving datetime

[Nicholas F. Fabry]

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