Concerning Time.TimeDiff

[John Meacham]

On Tue, Jun 17, 2003 at 08:58:54PM -0400, Matthew Donadio wrote:
> John Meacham wrote:
> > UNIX hacks
> > around this by changing the length of a second around a leap second, so
> > every timestamp when interpreted as an offset from epoch without any
> > leap seconds (i.e. every minute is 60 seconds) is correct, but the
> > tradeoff is that the length of a second is no longer defined and you
> > can't do time arithmetic or time offsets correctly.
> 
> Are current libraries really this brain dead?  I haven't dealt with time
> in almost 10 years, and always had very strict requirements (timetaging
> satellite telemetry).  Sloppiness like that really surprises me.

yup. unfortunatly this brokenness is mandated by POSIX:

  POSIX.1 defines seconds since the Epoch as a value to be interpreted as
  the number of seconds between a specified time and the Epoch, according
  to a formula for conversion from UTC equivalent to conversion on the na
  basis  that  leap  seconds are ignored and all years divisible by 4 are
  leap years.  This value is not the same as the actual number of seconds
  between  the  time  and  the Epoch, because of leap seconds and because
  clocks are not required to be synchronised  to a  standard reference.
  The  intention  is  that  the interpretation of seconds since the Epoch
  values be consistent; see POSIX.1 Annex B 2.2.2 for further rationale.


the only way to reconcile the POSIX time with real time is by changing
the speed of  the clock and hence the length of a POSIX second. even
worse, POSIX got the formula for leap years wrong so you have to make up
for a whole day at times (!!)  (if you follow the standard exactly, the
leap year problem is considered a typo by many). in any case, anyone who
wants accurate times uses an alternate library such as djb's libtai or
rolls their own solution.

Using TAI internally and only dealing with UTC when translating between
CalendarTimes has a number of advantages, CalendarTime already has a
timezone field, so it is not even that odd to expect it to translate the
time to UTC if that "timezone" is specified. TAI is well defined for
arbitrary times in the past, using an 'Integer' means we can represent
times accuratly across all of history and the future. :) This makes the
native Time type in haskell suitable for actual scientific work, which
is good. 

the only source of confusion I can think of is if the Integer
representing TAI relative to epoch is misinterpreted as a time_t
equivalent under POSIX, providing toPosixUTC :: ClockTime -> Integer
and fromPosixUTC :: Integer -> ClockTime would be useful and advisable

        John



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