Implementability and Time.TimeDiff

John Meacham
Fri, 20 Jun 2003 17:19:25 -0700

yeah. it is expected that many systems will not be able to fully conform
to this standard. but getting pretty close is good enough for most
applications, however we need to actually give the standard routines
defined semantics if they are to be useful. At least by defining
ClockTime in terms of TAI we can actually use the value to represent
real times in the future and past and perform arithmetic on it that
makes sense, this is quite useful functionality in general, imagine an
accounting program that reads in a bunch of times, performs some
operations on them and spits the times back out into another file, the
fact that the system doesn't quite conform DOESN'T matter because we are
never actually using the systems time functionality. Not concretly
specifying what ClockTime means because not all systems have a concrete
definition of their own time would be foolish, lots of applications
don't need to access the current time yet want to work with dates and

On Sat, Jun 21, 2003 at 12:59:27AM +0200, Dylan Thurston wrote:
> On Fri, Jun 20, 2003 at 01:45:03PM -0700, John Meacham wrote:
> > On Fri, Jun 20, 2003 at 07:36:23PM +0200, Dylan Thurston wrote:
> > > Should there also be a function to get offsets (in seconds) between
> > > UTC and TAI?
> On reflection, I think this is too precise information to be
> accessible from a portable library.  In particular, I'm not sure it's
> possible to correctly implement a TAI-based time system on most Linux
> distributions without modification (I was rather shocked to discover
> this...), and I'm sure there are some desired platforms for Haskell
> which make it very hard to implement that.  So the standard should
> _allow_ for correct implementations, but not _require_ it.
there are lots of third party libraries which provide this
functionality, they are vital for many types of scientific computing. it
is quite plausable that a haskell implementation might use such a
library if it finds it. This is not just for current implementations but
a proposal for inclusion in Haskell proper. (I wish we could consider
the current Time library a big typo and retroactivly change haskell
98..) Any explicitly undefined or implementation dependent behavior will
be a source of problems, by giving a precise if not always obtainable
definition we can at least guarentee that all implementations are
shooting for the same goal..

> > yes. this would solve another problem I mentioned in a different email
> > about the user implementing their own time types and needing the raw
> > leap second info. perhaps:
> > 
> > leapSeconds :: ClockTime -> Int
> > ...
> That's probably too precise: perhaps the implementation has no access
> to raw leap seconds, or perhaps the standard changes and the offset is
> no longer an integer number of seconds.

if the implementation doesn't have access to raw leap seconds then an
embedded table could be used as a heuristic. This functionality is
mainly just useful for people that want to look at what Haskell is using
internally as I could see situations when it would be useful. Most
systems fudge this anyway, at least in Haskell we will be providing a
way to see exactly how the implementation is fudging it :) Think of it
as not 'what are the leap seconds' but 'what do you think the leap
seconds are?'

John Meacham - California Institute of Technology, Alum. -