Leaving aside issues of UTC detection, timezone detection, etc by using rdate, here are some thoughts on when d-i should set the date. Some different scenarios: * clock obviously not set correctly This can be identified in various ways, but if the clock is clearly not set right (ie, 1970, or < d-i image build date) then it should be ok for d-i to run rdate and hwclock to set it. * broken clock/no kernel support If d-i can detect this, the best thing to do is run rdate in the installer, and install ntp. I'm assuming that we don't want to install ntp by default everywhere, for various reasons. Ways to detect this include: Hardcoded subarch lists, probing the hwclock to detect stuck clocks[1] (would need a hwclock udeb), or maybe looking at kernel stuff to see if the kernel is happy with the clock. * other OS installed If os-prober finds another OS, then d-i probably shouldn't touch the clock, under the assumption that it's already set up as part of that other OS's install/use. * UTC system with no other OS installed If clock-setup decides the system should be on UTC, in many cases the clock is not yet actually set to UTC. So d-i should set the clock. -- see shy jo [1] Yes, they do exist. :-)
Attachment:
signature.asc
Description: Digital signature