On Jul 9, 2012, at 1:31 PM, Warner Losh wrote: > On Jul 9, 2012, at 1:58 PM, Hal Murray wrote: > >> How often do systems need to get updated to track time zone changes? > > The ones that run on UTC? Never. > >> Has the US Congress stopped playing with DST rules? When was the last >> change in Indiana? > > When running UTC-based systems? These don't matter.
Never is a long time. The question here was about collecting use cases for requirements discovery. I can't be alone in maintaining systems that collect data from diverse timezones and that have to perform arithmetic on timestamps. Whether the local system timestamps are UTC is immaterial. Also, there are innumerable database applications pertaining to multi-timezone data in which prior timezone offsets (potentially including leap seconds, but dwarfed by shifting DST rules) have to be accommodated, potentially over many years. >> Or are we talking about systems that don't use time zones? If so, what >> sorts of things do they do? How big is the problem space at the >> intersection of time matters but updating a table is hard? > > There's two issues here. First, the current "right" database can't be > updated in place: you have to restart. Then an appropriate response would be to seek to make this responsive to a HUP or some other runtime command. > Second, there's the cold spare situation where you have a complete redundant > copy of the hardware to swap in when the primary copy fails. Since this is a > cold spare, sitting on a shelf, bringing them up every so often to get the > latest leap second information can be difficult, especially if the only place > that the plug into is where the primary lives... Cold systems can stay cold > much longer if the time horizon for leap seconds is expanded from 6 months. Noted. However, leap seconds are only one of possibly very many such evolving state variables. Our telescopes are scheduled on a semester basis. Many campus and real world processes are on a 6-month or annual basis. Some are much more rapidly evolving. (Even ignoring the intervening OS updates :-) The existence of cold spares implies some process for warming them up. That process includes updating the state. In Apollo 13 (movie and reality), the crew powered down the command module, transferring the state variables first to the computer on the cold-start LEM and then as they approached Earth back to the cold-restart CM. This is not a problem unique to leap seconds. How large a problem space is being intersected is a good question. Rob -- http://www.sciencephoto.com/media/458565/enlarge _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
