[Trac-dev] Sandbox proposal: datetime
Jonas Borgström
jonas at edgewall.com
Mon Jul 17 12:08:53 CDT 2006
Hi,
I think it's time for Trac to switch to python datetime objects as the
internal date/time representation. Trac currently uses unix timestamps
(number of seconds since Jan 1 1970) since that was the only alternative
back when we supported Python >= 2.1.
Advantages:
* Time zone support. It will be possible for each user to store their
preferred time zone in the session. It might also be able to
auto-detect a users time zone using some javascript magic.
Basic time zone support can be implemented without adding a
dependency on additional modules such as pytz. We could detect if
pytz is installed and provide more correct time zone support (DST).
* Cleaner code. The python datetime module contains a lot of useful
functionality that will make it easier to work with dates.
Disadvantages:
* API compatibility: A few methods will start to expect datetime
objects instead of integers. This might not be such a big issue since
this branch will not be merged until at least 0.11 or 0.12.
Much similar to the previous unicode branch this branch will convert all
unix timestamps into datetime objects as soon as they're fetched from
the database. All code except the "database layer" will work exclusively
with datetime objects.
Any thoughts?
/ Jonas
http://trac.edgewall.org/ticket/17
More information about the Trac-dev
mailing list