I cannot be the only one who finds these discussions tedious. The archives contain more than a hundred threads very much like this one. The same issues are discussed, more or less inadequately, over and over again.
Sanely organized networks, even those that do not span multiple time zones, collect and store only UTC [GMT] STCKE values. It is then of course possible to write trivial routines that, given a UTC offset, display or print local clock times, absurd 12-hour ones in the United States [and, apparently, parts of Canada too] and 24-hour ones elsewhere. Insanely organized networks must always collect vector-valued times, i.e., an STCKE value and its associated (fixed-point NOT integer) UTC offset. The raw conversion of STCKE-instruction values without the use of a leap-second table is an indefensible practice that convicts its perpetrator of radical ignorance and/or technical incompetence. The table involved is short; it is ordered; it can be searched using very efficient glb-seeking binary search; this table grows very slowly; elements can be added to it before their effective dates; ample advance notice of requirements to add new elements and their effective dates (always one of two) is provided; etc., etc. [The detailed design of this table should make provision for negative leap-second corrections, but that is a trivial matter.] John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
