Time Library Organisation

[Keean Schupke]

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 
functions.

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...
allowing:

    localtime getTime Paris Mayan) -- to get the local time in paris 
calculated using the Mayan  calendar.

    Keean.