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