Peter Thiemann (Mon, Feb 10, 2003 at 04:36:17PM -0800): > >>>>> "Stefan" == Stefan Karrmann <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/haskell -- Stefan Karrmann _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell