[email protected] said: > Even if you only consider physical hardware, based on the projected > lifetime of automotive qualified systems (15 years or longer) you have to > expect a much longer actual lifetime in the field.
[email protected] said: > 19:14 <ianbruene> One should always put a multiplier on one's > estimate of how long their code will be in use: code expected to > last for 5 years lasting 20 got us Y2K. ... Right. I think there are two issues tangled up here. One is that there is a tradeoff between building in a long lifetime and catching problems during a normal lifetime. I'm not sure which is more likely. Consider what happens if a server gets fired up with a broken clock and starts answering all requests with 1970. Do you want to reject that, or pivot it to 2036? The other is that there really is a 20 year rollover with old GPS units. (Newer units have 13 bits.) I think that turns into 3 choices: Don't support really old GPS units. Advertise the default lifetime. Allow the user to specify the pivot time and/or life time, either at build time or at run time or both. --------- How long have computers been used in cars? When did they start using software complicated enough to support a system time-of-day clock? What's their track record for long lifetime bugs? -- These are my opinions. I hate spam. _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
