Chris Albertson <[email protected]> wrote: > It's even less logical than that. With "rubber seconds" tied to the > Earth's rotation. You ultra stable cesium clock is no longer running > at a fixed frequency.
Wait a minute here, Chris... Weren't you just telling me the other day how important it is to maintain a distinction between primary requirements, derived requirements and implementation details? Cesium clocks and whatnot are implementation details, so let's set them aside until we cover the primary requirements. There two fundamentally different kinds of time: interval time and time-of-day. I realize that this mailing list is mostly inhabited by people who care the most about the former, but there are some people for whom the latter (time-of-day) is much more important. I am one of the latter people. Since the beginning of human civilisation the notion of time of day had absolutely nothing to do with interval time. Interval time is a strictly relative measure, yet ToD has always been an absolute measure of Earth's position in the heavens. (In the minds of the ancient peoples it was relative to the gods.) I wish to preserve the millennia-old time-of-day that is completely separate and independent from interval time. For me that is a basic primary requirement. As an engineer faced with an external requirement, you can be as innovative as you want with how you implement it, but you don't get to negate the requirement itself - basic primary requirements are non-negotiable. In my case the hard requirement is to provide a form of "time" that represents Earth's position in heavens, just like the word "time" has been defined for all those millennia before atomic clocks. That is a hard non-negotiable requirement. If this requirement is a pita for cesium clocks, tough. Don't use a cesium clock if that device is not suitable for the given task of satisfying the requirement at hand. > (2) define the day as 60 x 60 x 24 seconds long. And let the length of > a second be continuously variable or > [...] > Using #2 makes the job of maintaining a frequency standard more interesting. I have never advocated for use of rubber seconds in frequency standards. Frequency is the inverse of time interval, *not* of "true time" as in time-of-day, hence it belongs in an entirely different department. Clearly there exists a need for both kinds of time. I have always advocated for a two-tier time distribution architecture: 1. At the lower level you have your atomic clocks that tick independent of the Earth's rotation. Use this timescale for all your "techie" applications, but *please* don't try to forcibly impose it on anyone who has not explicitly opted in. 2. At the higher "user-friendly" level, rubber duckies like the one I'm about to build take this fancy non-Earth-rotation-based "techie time" as input and produce old-fashioned Earth orientation time on output, or more precisely produce a synthetic timescale that is rubberized to pass as an acceptable approximation of the Earth's true position in the heavens relative to the gods. Use *this* time for civil/social purposes, i.e., to tell grandmothers when to go to church, don't make them switch to Earth-decoupled time. MS _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
