System.Time.Clock Design Issues

[S. Alexander Jacobson]

On Thu, 3 Feb 2005, Simon Marlow wrote:
> I don't think we need this either, at lesat not in the external
> interface.  Any calculations you can do with this type you can do on a
> calendar time.

The problem is that a sane calendar time depends a 
lot on the application.  Forcing physicists and 
engineers to deal with human constructs like Year 
and Month seems annoying at the very least! 
Personally, I would prefer a representation that 
is very storage efficient and I don't know that 
"calendar time" would guarantee that.

I think we actually have a few different use cases 
here that it would be helpful to elucidate.  Note 
I am not a user in most of these cases so feel 
free to refine.  This is a strawman.

Mathematical Time
-----------------
This is an infinitely large, infinitely precise 
quantity useful only to people doing theoretical 
stuff.

   data MathTime = MathTime Integer Rational

Note: Calendar overhead seeems really pointless 
for this userbase.  I am not even certain that 
these people need anything from System.* but am 
keeping an open mind here.

Engineering Time
----------------
Keann's example is building rockets, but the 
general concept is that we need to compare a 
system clock at two different times.  So the 
system clock needs to return a duration since some 
official time in units corresponding to the 
resolution of the system clock.

   getClockTime::IO Integer
   getClockPrecision::IO Units

Note: I don't know how to specify units here. 
Perhaps units are specified in an Integer which 
identifies the denominator of the smallest 
measurable fraction of a second.

Server Time
-----------
For the vast majority of applications we probably 
want the much more simple:

   type Seconds=Integer
   getClockSeconds::IO Integer
   getClockMillis::IO Integer

Here I am a user.  I like having a definition like 
this because I am space constrained and would much 
prefer to store Ints than whole wasteful 
CalendarTime constructs.  Calendars are important 
only at the front end.

User/Calendar Time
------------------
Different users require different representations 
of time and duration in different applications. 
Various calendars would handle leap seconds, 
timezones, DST, and units for various application 
contexts.

These different sorts of representations should be 
localized to different libraries like:

   Calendar.RFC822
   Calendar.Julian
   Calendar.Muslim
   Calendar.Hebrew
   Calendar.UTC
   Calendar.TAI
   Calendar.Dog

The main thing we then need is a standard 
interface to communicate between them.

   class CalTime calTime where
     fromClockTime::->Units->Integer->calTime
     fromSeconds::Seconds->calTime
     toSeconds::calTime->Seconds
     diffCalTime::calTime->calTime->Seconds
     addCalTime::calTime->Seconds->calTime

I hope this makes sense.  In any case, it is just 
a strawman.  Burn at will.

-Alex-


______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com