System.Time.Clock Design Issues

S. Alexander Jacobson haskell at alexjacobson.com
Thu Feb 3 10:57:19 EST 2005

```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