On Wed 2010-12-22T09:51:15 -0800, Steve Allen hath writ: > It happens that I am refactoring just such code at this moment. > It is very sloppy code that ignores timezone issues and hopes that > nobody will notice if the event happens a little off once is a while.
Parenthetically, this code is sloppy in a unique way. I wrote and oversee the system which manufactures slitmasks for the spectrographs on the Keck telescopes. I am accustomed to watching this activity vary by the phase of the moon. However these slitmask events consist of submissions by humans and mill operations by humans, so while the timing of this industrial process is modulated by the moon, it is not strictly controlled by the moon. In contrast the code I'm am rewriting today occasionally encounters a non-fatal off-by-one array indexing error. The error only occurs during a window which is open for a few hours of the day 2 weeks before a quarter phase of the moon. So the real trick of assessing the effect of changing the name of the broadcast time scale lies in classifying and distinguishing such as => processes which are modulated by time of day but implemented by humans (no adverse effect) => processes which are controlled by time of day but do not have significant (fatal) consequences of being off by a few seconds => processes which will kill or destroy things if their clocks are unhappy with a difference between broadcast time and civil time Can anyone give specific examples of the last? Are there other classifications or ways of making distinctions? -- Steve Allen <s...@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
