Improving datetime

[Christian Heimes]

Nicholas F. Fabry schrieb:
> 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.

Yes, it sounds like a good idea. The low hanging fruits (aka easy tasks) 
could be implemented for 2.6 and 3.0. The more complex tasks may have to 
wait for 2.7 and 3.1

Apropos time zones. A while ago I proposed the inclusion of pytz. But 
Stuart argued that the tz database may change monthly so I retracted my 
proposal. But Stuart has proposed some improvements for datetime's tz 
class. I suggest you contact him.

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

Some people tend to start their postings like:

In the year 2008 after the birth of Christ I, the son of Jone, son of 
James ...

Do you get my point? :] I suggest you start with a short introduction of 
yourself and your proposal. Short paragraphs and short sentences are 
easier to read than long. You'll do fine ;)


Christian