Improving datetime

[Nicholas F. Fabry]

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