On Mar 21, 2008, at 13:36, Christian Heimes wrote:
> Colin J. Williams schrieb:
>> You might consider adding the Julian date
>> (http://en.wikipedia.org/wiki/Julian_date).
>>
>> I had a crack at this a while ago but didn't seem to get quire the
>> right
>> result, using the ACM algorithm. I seemed to be a day out at the
>> BC/AD
>> divide.
>
> Yes, the Julian date family is very useful when dealing with dates
> before 1900. I'm +1 for adding JDT and MJD.
>
> TAI64 is another time format used for high precision and real time
> measurement. http://cr.yp.to/libtai/tai64.html
>
This is that 'feature creep' thing I keep reading about on Dilbert,
eh? ;-)
Obviously, this would not be considered an 'easy bit' - however, the
basic datetime.datetime class needs overhauling anyway when we get to
the harder bits. So, it's worth determining whether we just want to
have it run in the proleptic Gregorian calendar (ISO 8601), or figure
out other calendars as well. I don't know anything about TAI64, but
I'll read about it. The Julian I do know about (rioting after
'losing' 10 days? Sheesh!) - it was a pretty reasonable swag at
hitting the solar year for its time....
<wild speculations>
Perhaps it might be wise to consider a 'calendar definition object' -
I'll dub it a calinfo object for now - that allows third parties to
develop a set of rules that define a) how to count in a calendar, and
b) how to translate unambiguously from one calendar to another. This
suggests that we need a 'standard' calendar, much like UTC is the
default timezone for calculations; the proleptic Gregorian seems like
the obvious choice for now.
So, a new 'superaware' datetime object represents a moment in time and
would have:
a local datetime, representing what 'local' clocks and calendar
indicate at that time
a UTC datetime, representing what UTC clocks and calendar indicate at
that time
a tzinfo object, encapsulating the the rules for translating local
times to/from UTC, and
a calinfo object, encapsulating:
the calculation rules for adding & subtracting timedeltas to datetimes
the calculation rules for finding the timedelta between two datetimes
the translation rules for converting a datetime with a calinfo object
into a datetime with a 'standard' calinfo object
With time zones, because their offsets regularly swing back and forth,
we have issues with illegal and ambiguous local times. I don't know
much about different calendars - I am somewhat sure for Gregorian <-->
Julian there are no ambiguities or 'illegal' dates, but I don't know
about other calendars.
I haven't thought of this before. I need to mull over how to do this
- if we are going to spend the time developing three different methods
of calculations for three different calendars, and I know there are
other calendar systems in the world, it strikes me that the forward
thinking thing to do is figure out how to abstract the calendar rule
concept, develop a few common examples, and leave it to others
(initially) to develop other calendars, much as third parties
implemented concrete tzinfo subclasses. In doing so, they revealed
some of the present limitations with the current implementation of
datetime, that we are now considering updating. We may not have
enough experience here of other calendar systems to get this totally
right on the first go round, but it sounds worth a try....
</wild speculations>
> Christian
>
P.S. By Stewart, I assume you mean the author of pytz? And I think I
got the 'no novel' concept - write for people who understand the basic
ideas already. Have a good weekend!
Nick
> --
> http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
