[DB-SIG] Standardized Date-Time class
Jeffrey C. Jacobs
Tue, 9 Dec 1997 17:07:01 -0500
This is my first post to the DB Sig, and I may be a day or so out of =
step with the rest of you, but I have been talking with Prof. Reingold, =
the author of the Calendar converter written in C mentioned by Christian =
Egli yesterday, and he possesses many other calendar converters which he =
is not making available to the general public, but would allow to be =
distributed freely if for non-commercial use in Python form based on the =
original Lisp code. Thus, it would be nice if we do build a Calendar =
converter into the Date-Time object, that the converters can be loaded =
modularly, so that if a non-commercial entity wishes to use the =
Reingold-Dershowitz algorithms, they may just plug them in, but =
otherwise they need not be included. In this way, each Calendar could =
be loaded optionally, so that if one was only concerned with Gregorian =
and ISO, one wouldn't have to load Hebrew, Islamic or Mayan.
Grabbing the statements from Jim Fulton mentioned before:
> It would be helpful to have a standard date-time implementation for
> use in Python database implementations (and elsewhere, of course).
> I think that the date-time implementation should:
> 1. Support conversion from strings in a very wide variety of formats
> (e.g. 'Oct, 1, 1994 12:34am EST', '1994/10/1 00:34:21.456')
This would be calendar dependent, and thus reside in a given Calendar's =
module, however, if I write "1 Juli 1972", "1er Janvier", or "15 Maggio =
44 B.C.", how would those be interpreted? And if I write "97/12/09", as =
I would in Japan, will it know what I mean?
> 2. Support subtraction of date-times, and addition and=20
> subtraction of dates and numbers.
I think the general idea that time is actually two concepts, Time and =
TimeSpan, may be the best way of looking at this, and since the way =
Times are stored may not necessarily be in Seconds since some standard =
Epoch, adding a number to a Time may be confusing: "What am I adding? =
Seconds? Milliseconds? Days? Floating point? Integer?" Where as a =
TimeSpan class could be created as a co-class of Time, using the same =
storage format, and having interfaces which make it clear the span of =
time stored in the object.
> 3. Store dates efficiently.
I would think that Dates and Time being basically one concept, should =
be combined into 1 Time class, and given the precision of most computers =
purporting to be in milliseconds, a very simple way of storing Dates =
would be a long indicating the number of Milliseconds since some epoch. =
The Gregorian epoch then would be a logical choice, making it the =
default calendar; the number of Milliseconds expired since Monday, 1 =
January 1 AD at 00:00:00.000 UTC would certainly be my suggestion.
You never know if you want to calculate the time the Earth was created =
as Tuesday, 4 November 5,371,840,012 BC at 12:36:14.009 UTC (in a =
non-secular context); a floating point will over-flow, though a long =
will maintain precision. I know, how often are you going to need to use =
the day the Earth was created, but isn't it nice knowing that you *can*? =
Thus, the TimeSpan would also be a quantity in Milliseconds, though =
such an object may be initialized in Days or Seconds, I should think.
Of course, if most calculations are done based on Seconds or Days, then =
this storage method is not optimal.
> 4. Store dates immutably.
I may sound stupid with this one, but if the module is written in =
python, and not compiled, then theoretically wouldn't you always be able =
to change the internal structure of your Time class? Say I write:
> foo =3D TimeModule.Time(time.time()) # foo =3D The Current Time
> foo.MyInternalTimeStorage =3D 42
'January 1, 1 AD 00:00:00.042 UTC'
There may be a way around this in Python, but alas I don't know it. =
Thus, the only way I know to achieve true immutability would be to write =
the Time and TimeSpan classes in C++ and then compile that to a Python =
module. I guess I can leave this issue to someone else who would know =
more about this aspect of Python than I.
> 5. Represent dates to a specified minimum precision=20
> (e.g. milliseconds).
> 6. Handle all dates in the Gregorian calendar. (e.g. there should
> not be problems storing dates from the 18th or 21st centuries.)
As I said above, supporting non-Gregorian calendars may be made =
optional, but the Gregorian module should be loaded with the TimeModule, =
and therefore support of arbitrary Gregorian dates should be feasible.
> 7. Provide read-access to date-components (e.g. year, month, second,
> day-of-week, etc.)
That would also be an aspect of each Calendar module, such as the =
default Gregorian type, though given how I have set up the Calendar =
definition, each quantity would have to be calculated dynamically.
> I'm afraid the implementation should also address issues like:
> 8. Support for time-zones,
> 9. Support for daylight-savings time.
Having examined and pilfered the definitions for 51 standard TimeZones =
and their corresponding rules for DST, this should be doable as a simple =
look-up, with some minor calculations. The C-Library support for DST =
that I have is based on these rules and doing a lookup for which is the =
local TimeZone using an OS API. Since I think normally the TimeZone is =
stored in the environment variable "TZ" as a string of the form =
"GMTh[:m[:s]][GDT]", I am lead to believe that if the GDT string is =
included, indicating that this TimeZone supports Daylight Savings, then =
the offset will always be 1 hour, begins the first Sunday in April at =
02:00:00 and ending the last Sunday in October at 02:00:00. Since this =
is not at all valid universally, especially in countries in the southern =
hemisphere or outside Europe and North America, storing the DST rules as =
well as the name would seem wise.
However, given the list of TimeZones that I have, all the names are in =
full format, "Greenwich Mean Time", not "GMT", which is what is =
reflected in Python when I type "> time.tzname". If some other system =
is using the 3-Character form, the lookup will have to be modified so =
that that TimeZone can be found in the list of TimeZones.
Another issue which may be important is that in the US, the rules for =
when DST begins I believe were changed from beginning the last Sunday in =
April to the current rules in 1987, so what do we calculate for the Time =
in mid April in the US before 1987? Could TimeZones have more than one =
set of Daylight Savings rules depending on the year being calculated?
What I'm getting at here, is if we are going to support Universal Time =
from 5 billion BC to 1 billion AD or what have you, we will have to =
replace the C-Library TimeZone routines with something more robust. I'm =
currently examining the GNU implementation of TimeZones and I may =
elaborate on this in a later post.
Just as in interesting aside, one thing I have found is that since Leap =
Seconds have been instituted in 1972, there have been 21 occurrences as =
of 30 June 1997, thus any times before 1972 will be off by about 21 =
One final and potential To Do, coming full circle on the whole Calendar =
concept: since in Hebrew and Islamic calendars the day begins at =
Sundown, wouldn't implementation of Sunrise and Sunset calculations make =
things more precise, if they could also be included optionally? =
Certainly, this would be a very low priority.
Anyway, those are my thoughts on Time based on the work I have been =
doing so far in Python building my own Time and Calendar modules, which =
I will try to post when I work out some structural issues, such as =
standardizing the Calendar modules and getting everything to be in =
Be Seeing You,
~,-;` The TimeHorse
Sometimes also a Dragon. . .
DB-SIG - SIG on Tabular Databases in Python
send messages to: firstname.lastname@example.org
administrivia to: email@example.com