On Tue, Feb 16, 2010 at 02:38, anatoly techtonik <techto...@gmail.com> wrote: > Hello, > > So far, Python timezone handling is far from "pythonic". There is no > function to get current UTC offset, intuitive API to get DST of > current time zone and whenever it is active, no functions to work with > internet timestamps (RFC 3339). In my case [1] it took about one month > and five people to get the right solution for a valid RFC 3339 > timestamp. One of the reasons I see is that date/time functions are > implemented in C, they expose C API, and there are not many people who > can help and patch them. > > I am sure many current Python users will appreciate UTC functions and > improved date/time API more than any new language features. That's why > I would like to propose this enhancements for a coding spring on > forthcoming PyCon. I am located in Europe and can't attend PyCon, but > I summarized date/time issues related to UTC below. > > More open UTC-related Python issues: > http://bugs.python.org/issue1647654 No obvious and correct way to get > the time zone offset > http://bugs.python.org/issue1667546 Time zone-capable variant of > time.localtime > http://bugs.python.org/issue7662 time.utcoffset() > http://bugs.python.org/issue7229 [PATCH] Manual entry for > time.daylight can be misleading > http://bugs.python.org/issue5094 datetime lacks concrete tzinfo > impl. for UTC
Issue 5094 already has a patch that is nearly complete to provide a default UTC object (and requisite changes to functions to no longer be naive but to use UTC). I did a code review on it in Rietveld and it only has minor things to correct. > http://bugs.python.org/issue7584 datetime.rfcformat() for Date and > Time on the Internet (support RFC 3339, ISO 8601 datetime format) > http://bugs.python.org/issue665194 datetime-RFC2822 roundtripping > http://bugs.python.org/issue6280 calendar.timegm() belongs in time > module, next to time.gmtime() > > All solutions require C expertise. If it will be impossible to find > experts able to modify current implementation, then perhaps it could > be real to create Python stub for coding solution in Python later? Probably worth doing as I am sure everyone would prefer to maintain a pure Python version when possible and only drop into C as needed. See heapq, warnings, and a couple of others if you don't know how to properly do a Python/C module split. -Brett > > FWIW, this proposal is from my other issue about problems with Python > date/time in separate tracker on Google Code [2]. > > [1] http://bugs.python.org/issue7582 [patch] diff.py to use iso timestamp > [2] http://code.google.com/p/rainforce/issues/detail?id=10 python: > date/time is a mess > -- > anatoly t. > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
