Frans Pop wrote: > There is a danger in that anyway. > Some packages (like chrony) take the value of $UTC in /etc/default/rcS > when they are first installed. However, if you change $UTC, the new value > is not automatically applied in these other packages. I hope someone has filed a bug on those packages, since that's fairly stupid behavior. > You mean "if some kind of Windows present then set to local time"? That's > a fairly wild assumption... > What about ppl who had Windows on their system but have deleted it as part > of the install? Their clock will probably be set to local time. I guess > in that situation being able to set the clock would actually make > sense... The same goes for new systems (just out of the shop). There's no > way of knowing what the clock will be set to. Part of the problem with how we've handled this before is we've not had a clear distinction of whether the point is to help the user choose the UTC/localtime setting that makes their clock be (close to) correct time w/o being manually set -- or whether the point is to help the user choose a UTC/localtime setting that is correct for the software mix on their system. I think the second thing is the right thing for the installer to prioritise. Realistically, clocks are likely enough to be wrong on new systems[1] that we need to assume the user will want to set the clock anyway. And setting a clock is not hard, it's something people understand, and something that both GUIs and ntp clients make easy. "Is your clock set to UTC?" is _not_ something people understand, so we should try to avoid it. The code I've just checked in avoids asking it in high priority mode unless there is some other OS than DOS/Windows detected. If that means we always prompt the user to set their clock then that's ok, although I'm still tempted to leave this up to the post-install GUI or a ntp client (which d-i should then take care of installing). > Hardcoding to GMT for some platforms does make sense IMO. Any idea which ones? (besides s390 which has no hwclock) For example, is there any reason at all to worry about it on sparc? -- see shy jo [1] clock drift, box shipped from other timezone, etc, etc
Attachment:
signature.asc
Description: Digital signature