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.
This is an infinitely large, infinitely precise
quantity useful only to people doing theoretical
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.
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.
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.
For the vast majority of applications we probably
want the much more simple:
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.
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
These different sorts of representations should be
localized to different libraries like:
The main thing we then need is a standard
interface to communicate between them.
class CalTime calTime where
I hope this makes sense. In any case, it is just
a strawman. Burn at will.
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
More information about the Libraries