Hello everyone,

what a coincidence. I just was discussing this issue with Jason O. today. Here is my original mail:

Hey Jason,

I also want to start to think about a DateTime module. PostGres has a nice discussion of their impementation: http://www.ca.postgresql.org/users-lounge/docs/7.1/user/datatype-datetime.html

Here is Java's stuff on it:

Low Level Data Types:

TimeStamp - Timestamps are always in UTC.

* Intervals can be added or subtracted from themselves and the types above.


- The basic data type must be as small as possible, so that applications that save these types often (i.e. ZODB/Persistent) then it should not increase the amount of data by much.

- We should then have high-level classes that put in all the functionality, such as lower-level in/output. I think high-level in/output should be handled by functions inside the module, such as getDateTimeFromString(str, someI18NspecificInfo=None).

- We need flexible i18n support!!! This is very important, especially for Zope. By default the system should come with a gettext implementation, but I would like to have the module generic enough that we can define other types of translation and localization mechanisms. Mh, the more I think of it, the more I think we will end up building our own stuff and then exposing that via an API.

- The parsing of Date, Time and DateTimes as well as their Intervals (PostGreSQL has some very nice ways for that) should be tremendously flexible. I am thinking here about a plugin-type architecture, where you can create your own plugins for parsing. For example, while the "." notation was reserved for the European Date Formats until now, more and more American companies (which are totally ignorant that there might be another country besides the US in the world) use this notation to write the American Date Format this way too. Therefore we need to have a mechanism to switch between the two.
I thought of some sort of a list of regex expressions which try to resolve a string. Oh yeah, we need internationalization here as well of course, even though the parser should be generic enough.

- The tough part will be time zones. I am almost thinking that we need our own object for handling that. Timezones are horribly complex, but we need to handle them well. I know Zope's current DateTime implementation has a good handle on that, even though I think the code is horrible (sorry Jim).

- A professor just mentioned that we should also handle daylight saving. This is not even that trivial, but I agree with him; there needs to be support for that, even though most apps handle that via the time zone, which is ok for the numeric version, but not if you say "CST" for example.

PS: Jim, I cc'ed you so that you might be able to comment in some of the points I made. FYI, Jason and I think about implementing a DateTime module for Python in general, which is small and sweet. We are shooting for our calendar system only.


Stephan Richter
CBU - Physics and Chemistry Student
Web2k - Web Design/Development & Technical Project Management