[OT] Re: time since the epoch

[Stefan Karrmann]

Peter Thiemann (Mon, Feb 10, 2003 at 04:36:17PM -0800):
> >>>>> "Stefan" == Stefan Karrmann <sk@mathematik.uni-ulm.de> writes:
> 
>     Stefan> Peter Thiemann (Thu, Feb 06, 2003 at 12:40:14PM -0800):
>     >> John's code illustrates TimeDiff's deficiencies perfectly:
>     >> 
>     >> There is also a more fundamental problem with the TimeDiff data
>     >> type. While seconds, minutes, hours, and days are clearly specified
>     >> amounts of time, the duration of a month or a year may vary depending
>     >> on the reference point where the time difference is applied.
> 
>     Stefan> What time takes a year - 365 or 366 days? There are leap years!
>     Stefan> What time takes a month - 28, 29, 30 or 31 days?
>     Stefan> A week takes 7 days.
>     Stefan> How long is a day - 86399, 86400 or 86401 seconds and how long is a
>     Stefan> hour - 3599, 3600 or 3601 seconds? There are leap seconds!
>     Stefan> A second is the basic amount of time.
> 
> Minutes, hours, and days (even weeks) are also well defined in terms
> of seconds. But not months and years.

No! There are leap seconds which let some minute contain exactly 61 or 59
seconds!

Thus, you have a different fixed scales. The elements of each scale
are given by a FIXED number of the first element.:

1. Seconds (SI-unit), kilo seconds, etc.
2. Minute, hours, days, weaks
3. Months, years, decades, centuries, ages, etc.


>     >> My conclusion is that time differences really should be measured in
>     >> seconds and picoseconds. 
> 
>     Stefan> How do you measure 100 attoseconds?
1 attoseconds (1E-18 seconds) is a lot smaller then 1 picosecond.
> 
>     >> type TimeDiff = (Integer, Integer)

Should (x,y) :: TimeDiff mean the fractional x/y ?
If you still intend x to be seconds and y to be picoseconds you cannot
represent attoseconds .

>     Stefan> More general is
> 
>     Stefan> newtype TimeDiff = TimeDiff Rational
>     Stefan>    deriving (Eq, Ord)
> 
> I agree, I just was not bold enough to propose this :-)
> However, this seems to be close to the limit of the measurable, and
> I'm wondering how much precision is required in practice.

Here you are right. But if your calculations takes the same precision
adding rationals is cheap.

>     >> Hmm, this is underspecified!
>     >> As another poster said, (pointing out http://cr.yp.to/libtai, but it
>     >> is better to look at http://cr.yp.to/time.html, which has a discussion
>     >> on UTC vs TAI vs UNIX time) the official source of time is TAI, so it
>     >> is best to base a time library
>     >> *on the number of TAI seconds since a reference date*
>     >> (which is btw what the libtai is all about).
>     >> For compatibility with UNIX time, "Arthur David Olson's popular time
>     >> library uses an epoch of 1970-01-01 00:00:10 TAI"
>     >> [http://cr.yp.to/proto/utctai.html]. 
>     >> So this mostly means that you need to set your system clock correctly:-)
> 
>     Stefan> No, you have to check for leap seconds. There is one in
>     Stefan> every few years. 
> 
> I do not understand this comment. All I am saying is that you should
> set your system clock to the number of seconds since the epoch. Leap
> seconds only come into play when converting to UTC.
> 
> -- 
> Peter Thiemann, Prof. Dr.
> Institut für Informatik, Universität Freiburg, Germany
> http://www.informatik.uni-freiburg.de/~thiemann
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell

-- 
Stefan Karrmann