Concerning Time.TimeDiff

[John Meacham]

On Tue, Jun 17, 2003 at 09:00:15PM +0100, Jon Fairbairn wrote:
> On 2003-06-17 at 13:53BST "Simon Marlow" wrote:
> > -- * ClockTime
> > 
> > -- | A representation of absolute time
> > data ClockTime
> >   = ClockTime { ctSeconds :: Integer,
> >                 ctPicoseconds :: Integer }
> 
> Two Integer fields seems strange. Either 
>   ClockTime { ctPicoseconds :: Integer }

I strongly strongly agree with this. anything other than a single
Integer seems silly since we have arbitrary precision integers, we might
as well use them.

 
> would seem to make more sense. I don't see that saving a
> divide by 10^12 is a big win.  But being able to represent
> times shorter than a picosecond would be.
> 
> or
>   ClockTime { ctSeconds :: Integer, ctPicoseconds:: real }
> or, better
>   ClockTime { ctSeconds :: Ratio Integer }
> 

I would prefer not to complicate the Time type like this at the moment,
an ArbitraryTime or FracDuration type thing could be a seperate library.
Mainly I just want to fix the fact that the current time library is
completly unusable before worrying about extensions. 


> >   deriving (Eq, Ord, Show, Read)
> > 
> > -- | An empty 'TimeDiff'
> > noTimeDiff :: TimeDiff
> > 
TimeDiff might as well just be an Integer, same argument as for
ClockTime.

> > -- | Returns the difference between two 'ClockTime's
> 
> > -- * CalendarTime
> > 
> > data CalendarTime 
> >  = CalendarTime  {
> >      ctYear    :: Int,
> >      ctMonth   :: Month,
> >      ctDay     :: Int,
> >      ctHour    :: Int,
> >      ctMin     :: Int,
> >      ctSec     :: Int,
> >      ctPicosec :: Integer,
> >      ctTZ      :: Timezone
> >  }
> 
> again query Integer for picoseconds -- some sort of
> fractional value would be better.
> 
> > -- | Convert a 'CalendarTime' to a 'ClockTime'
> > -- TODO: can this raise an exception if the CalendarTime does not
> > -- represent a valid time?  Or should it return Maybe ClockTime?
> > calendarTimeToClockTime :: CalendarTime -> ClockTime
> 
> I'd vote for Maybe since it's more "functional" than
> exceptions.

me too.

as for the leap second issue, I suggest a simple solution inspired by
http://freebsd.ntu.edu.tw/djb/proto/utctai.html

ClockTimes and TimeDiffs are ALWAYS TAI with an epoch of 1970-01-01
00:00:10 TAI (to correspond to other libraries). a second is always a
second.  this greatly simplified the internals as simple arithmetic on
integers is always correct. 
the only time UTC and leap seconds should come into play is when
converting to or from a CalanderTime since UTC is meant to be a
human-consumable notion of time, not a precise one. We will have to
assume that an oracle exists to tell us which years had leap seconds in
them, but such information is required by any scheme which works with
UTC, many systems provide them and it is easy enough to embed a table.
        John




-- 
---------------------------------------------------------------------------
John Meacham - California Institute of Technology, Alum. - john@foo.net
---------------------------------------------------------------------------