Path: koobera.math.uic.edu!djb From: djb@koobera.math.uic.edu (D. J. Bernstein) Message-ID: <1997Aug2704.20.03.23977@koobera.math.uic.edu> Date: 27 Aug 1997 04:20:03 GMT Newsgroups: comp.protocols.time.ntp Subject: The meaning of n-second pauses in existing software References: <5tpph0$3sm$1@shade.twinsun.com> <1997Aug2420.38.00.26956@koobera.math.uic.edu> <5tr9bs$4qc$1@shade.twinsun.com> Organization: IR Paul Eggert wrote: > Many applications do things like add 3600 > seconds to get to the next hour; That's an interesting claim. Poking around the system I haven't spotted any 3600-second pauses, but I do see a pause measured in minutes, so let's talk about that. It's in the lock command. On this system it has a configurable timeout, measured in minutes. Let's set the timeout to 1 for simplicity. The lock command adds 60 seconds to the current time and sets an alarm for that moment. If you type ^D, it subtracts now from the alarm time and tells you how many seconds are left. Now, what is this 60-second delay supposed to do? 1. My theory: It's a 60-second delay. 2. Your theory: It's a delay ``to the next minute''---by which you mean adding 1 to the UTC minute counter, leaving seconds alone. What, pray tell, does your allegedly sensible operation do during a leap second? If the current time is ...:59:60 UTC, what does ``the next minute'' mean? Furthermore, why is anyone supposed to believe that your theory---a 60-second delay most of the time, except 61 on rare occasions---is what the program author intended? Or what users want? My theory is accurate to within a tiny percentage on the vast majority of UNIX systems. My theory is also supported by the man page, which says ``minutes,'' not ``minutes with leap seconds ignored.'' Now, if you don't think it's enough that your claim is meaningless, absurd, inaccurate, and contrary to the documentation, just let me know, and we can discuss timings in networking code. ---Dan Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html