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. > -- http://mail.python.org/mailman/listinfo/python-list
