Re: Improving datetime


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

.

Relevant Pages

  • Re: UTC conversion from different time zones
    ... but in my idea is the time in Net not real calendar based. ... But if you take something which is already UTC (because you've called ... I find the dateTime pretty good. ... DateTime had no idea whether it was a local time or a universal time - ...
    (microsoft.public.dotnet.general)
  • Re: Speed up UDF
    ... Actually a calendar table is pretty simple to use, ... RETURNS datetime ... declare @dtvar as datetime ...
    (comp.databases.ms-sqlserver)
  • Re: Calendar Stuff
    ... import calendar, datetime, time ... def calendarPrint: ...
    (comp.lang.python)
  • Re: converting single record with date range into multiple records
    ... Build a table for the buckets, or use an existing Calendar table: ... (bucket_start DATETIME NOT NULL PRIMARY KEY, ... FROM Parts AS P1, MonthBuckets AS B1 ...
    (microsoft.public.sqlserver.programming)
  • Re: DateTime problem
    ... Persian calendar is a solar calendar not unsimilar (but not too similar ... This can be used by specifying style 131 when converting datetime ... > convert, getdate(), 130), ...
    (microsoft.public.sqlserver.programming)