[Python-Dev] proposal: add basic time type to the standard
library
Stephan Richter
srichter@cbu.edu
Sat, 09 Feb 2002 01:22:37 -0600
--=====================_112555085==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
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:
http://www3.cbu.edu/sciences/jdk1.3/docs/api/java/sql/Date.html
Low Level Data Types:
Date
Time
DateTime
TimeStamp - Timestamps are always in UTC.
* Intervals can be added or subtracted from themselves and the types above.
DateInterval
TimeInterval
DateTimeInterval
TimeStampInterval
Notes:
- 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.
Regards,
Stephan
--
Stephan Richter
CBU - Physics and Chemistry Student
Web2k - Web Design/Development & Technical Project Management
--=====================_112555085==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
Hello everyone,<br><br>
what a coincidence. I just was discussing this issue with Jason O. today.
Here is my original mail:<br><br>
Hey Jason,<br><br>
I also want to start to think about a DateTime module. PostGres has a
nice discussion of their impementation:
<a href="http://www.ca.postgresql.org/users-lounge/docs/7.1/user/datatype-datetime.html" eudora="autourl"><font color="#0000FF"><u>http://www.ca.postgresql.org/users-lounge/docs/7.1/user/datatype-datetime.html<br><br>
</a></u></font>Here is Java's stuff on it: <br>
<font color="#0000FF"><u><a href="http://www3.cbu.edu/sciences/jdk1.3/docs/api/java/sql/Date.html" eudora="autourl">http://www3.cbu.edu/sciences/jdk1.3/docs/api/java/sql/Date.html<br><br>
<br>
</a></u></font>Low Level Data Types:<br><br>
Date<br>
Time<br>
DateTime<br>
TimeStamp - Timestamps are always in UTC.<br><br>
* Intervals can be added or subtracted from themselves and the types
above.<br>
DateInterval<br>
TimeInterval<br>
DateTimeInterval<br>
TimeStampInterval<br><br>
<br>
Notes:<br><br>
- 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.<br><br>
- 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).<br><br>
- 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.<br><br>
- 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. <br>
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.<br><br>
- 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). <br><br>
- 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. <br><br>
<br>
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.<br><br>
Regards,<br>
Stephan<br>
<x-sigsep><p></x-sigsep>
--<br>
Stephan Richter<br>
CBU - Physics and Chemistry Student<br>
Web2k - Web Design/Development & Technical Project Management</html>
--=====================_112555085==_.ALT--