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