[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