Concerning Time.TimeDiff

Graham Klyne GK@ninebynine.org
Fri, 20 Jun 2003 18:35:28 +0100


Ketil,

I've deliberately waited to respond.  Other discussion on this list 
suggests to me that actual implementations of Integer for which the actual 
values are within normal integer bounds are reasonably efficient, so that 
should not be a concern.  I'm thinking of running some tests against GHC 
and Hugs, to see how different implementation strategies perform.

At 15:11 19/06/03 +0200, Ketil Z. Malde wrote:
> > If the view is that Haskell is primarily for writing programs that are
> > provably correct in all conceivable circumstances, then the case for
> > using rational time values is clear.
>
>I don't think we should sacrifice correctness, it is a far greater
>problem for much more code, than speed is.

I entirely agree with that sentiment.

But I think that "correctness" is not always an absolute (except in a 
formal sense of conformance to specification) and there are more aspects to 
resource usage that mere computation speed.

For example, if a GPRS PDA is forced to connect to the Internet to check on 
leap second status before it can set off a wake-up alarm in the morning, I 
think that not using expensive connectivity is much more important that the 
accuracy of the alarm going off.

I don't claim you advocated this;  I just wanted to make the point that 
performance shouldn't completely be dismissed in favour of absolute 
correctness.

> > And the cost of supporting all this may be trivial in practical
> > terms -- I don't have a good handle on that, but I'll comment that
> > time calculations might be a significant computational burden for a
> > real-time system dealing with high event rates (and I think we'll
> > see lots of these applications).
>
>Could you be more concrete?  I don't think I know any system that
>spends a significant amount of time calculating dates.  Some systems
>that deal with time (GPS, NTP), mostly care about differences, and are
>happy to have the clock roll over relatively frequently.

Well (these may or may not not spend significant time doing date/time 
calculations), but, off the top of my head, the broad kinds of application 
I've been thinking of might be:
- e-commerce servers (delivery scheduling, session management, payment 
validity checks)
- network performance monitoring (even timing, frequency, delay measurements)
- security ticket server, e.g. Kerberos (calculating ticket diuration, 
checking ticket validity)
- personal information management (personal calendar, schedule, alarms)
- group information management (meeting scheduling, resource scheduling, 
alerts).
- just-in-time manufacturing scheduling (resource scheduling, production 
scheduling, real-time plant control in response to incoming requirements)
- network access control (time-restricted access, resource usage monitoring)
- network intrusion detection (event frequency and temporal pattern monitoring)

There's an application that I'm interested in working toward, even if I 
never get there, which is a semantic-web integrated real-time event 
handling system, whose broad goal is to integrate home security/home 
control features with personal and group schedules.  At the heart of this 
would be a database of RDF information describing a range of time-dependent 
events, and other things, linked with a real-time event handler and RDF 
inference meachanism (which is something I'm currently working on, in Haskell).

#g


-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E