I agree with David. Resetting the system clock is a potentially dangerous action. Examples: make(1) will fail to rebuild targets changed since the time correction but within the preexisting slew; cron jobs will fire twice or not at all. It should be done only at the administrator's request. Debconf should detect the slew, and say something like
"I can reset your clock using NTP now. Your current time is 11:17:03 JST; it will be reset by adding [subtracting] hh:mm:ss. It is possible that some applications will be adversely affected, such as make and cron, but it is normally safe to reset time on a personal workstation. (Note: if the slew is over 5 seconds and you do not reset now, ntpd will not adjust the time until you tell it to do so.) Shall I reset the time now? [Yes] [No]" In my case the slew was large: I live in Japan, made a fresh install of Debian to a Dell box, and (for reasons that escape me) the Etch installer didn't ask whether the hwclock was set to UTC or local time, but simply assumed UTC. Since Dell boxes (at least in Japan) come with the clock set to local time, I ended up 9 hours (and 31.74+ seconds :-) in the future. Yet installing ntp corrected that huge slew without asking me! 9 hours is a long time to live without make ;-) In my case, my intention was to run ntpdate immediately. In a sense this is convenient. But I don't run Debian for convenience; I run it because it's reliable and robust. Where I'm willing to sacrifice those properties for convenience, I run Ubuntu (or Mac OS X). I hope that Debian will continue to prefer robustness over convenience where they conflict. Thanks for your consideration. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]