Time Library Organisation
k.schupke at imperial.ac.uk
Wed Jan 26 04:05:10 EST 2005
Ashley Yakeley wrote:
>This is one way the time libraries might be organised. I think the
>functionality splits cleanly into two separate modules.
>"Time" module (System.Time? System.DateTime.Time?)
> * TAI/UTC arithmetic and conversions, leap-second tables
Im not an expert - but arn't leap-seconds connected with which calendar you
are using (not all calendars have 365 days a year)
> * possibly UT1 types and conversions, Julian days and dates
> * getting the current time
I would think that Time should be fudge-factor free... simply a number
of milliseconds after
the epoch... perhaps a 64bit number to avoid the unix Y2K problem which
I think is around 2030 (for a 32bit number)...
Another reason is daylight-savings (or British-Summer-Time) which means
the time of day changes, but of course when it changes from GMT to BST
depends on the calendar.
As such calculating localtime (hour of the day) depends on the day of
the year for some timezones... so this should be with the other calendar
So my vote goes for the unixy way of doing it, with a simple getTime
function that returns milliseconds after the epoch, and a library of
timezone/alternate calendar functions...
localtime getTime Paris Mayan) -- to get the local time in paris
calculated using the Mayan calendar.
More information about the Libraries