[Python-Dev] Add UTC to 2.7 (PyCon sprint idea)

[Brett Cannon]

On Tue, Feb 16, 2010 at 02:38, anatoly techtonik <techtonik at 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 at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
>