Time library

[Simon Marlow]

=20
> the point is not that subtracting 20 gives you the ability to do math,
> but that POSIX seconds are not equal to real seconds. a TAI second is
> equivalant to a standard second, A posix second is slightly=20
> longer than
> a normal second. The fact that the proposal specifices that=20
> ClockTime's
> are in picoseconds AND that the clocktime may be a POSIX timestamp are
> in direct violation with each other.=20
>=20
> Posix time_t's should not be thought of as an 'approximation' of real
> time or tai time, they have a well defined meaning and can accuratly
> represent specific times with slightly less than a second of accuracy.
> Treating them as representing standard seconds however is clearly
> incorrect, as they do not. they represent a number that can=20
> be trivially converted to an exact UTC time.=20

Ok, I see what you're saying.  Could you point to somewhere on the web
that describes this definition of POSIX time_t?  I looked in POSIX
1003.1-2003, and it has a different definition (the one I quoted
earlier).

http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html#t
ag_04_14

Indeed, the system I'm using here doesn't correspond to your definition
of POSIX time_t, it uses the definition from the link above.  To
clarify, under this definition of time_t, the clock ticks at second
intervals, but time_t cannot represent certain times.

Try the following code in GHC:

--------------------
import System.Time

date1 =3D CalendarTime {ctYear =3D 1998,
                    ctMonth =3D December,
                    ctDay =3D 31,
                    ctHour =3D 23,
                    ctMin =3D 59,
                    ctSec =3D 59,
                    ctPicosec =3D 0,
                    ctTZName =3D "GMT",
                    ctTZ =3D 0,
                    ctIsDST =3D False}

main =3D do
  print (toClockTime date1)
  print (case toClockTime date1 of TOD i j -> TOD (i+1) j)
--------------------

The program constructs a CalendarTime at the last point a leap second
occurred, converts it to time_t, adds one, and converts it back to
CalendarTime again.  Let's see what happens:

~/scratch > TZ=3DUTC ./timetest
Thu Dec 31 23:59:59 UTC 1998
Fri Jan  1 00:00:00 UTC 1999

Where's the leap second gone?  There are *two* real seconds between
these two times, yet I only added one to the time_t value.

~/scratch > TZ=3Dright/UTC ./timetest
Thu Dec 31 23:59:59 UTC 1998
Thu Dec 31 23:59:60 UTC 1998

Aha!  Setting TZ to "right/UTC" does the trick: now I can see the leap
second, because time_t includes leap seconds.

Cheers,
	Simon