On Tue, Jul 4, 2017 at 1:11 AM, Hans de Goede <hdegoede(a)redhat.com> wrote:
"Time and Date"
It is important to get the timezone setup correctly *before*
running the phase of anaconda where it formats filesystems
and copies files. Otherwise various tools may complain about
timestamps in the future for files created during install
time when the timezone is later changed in such a way
that the (timezone-adjusted) time becomes earlier.
We've had several bugs related to this in the past and
actually have moved timezone configuration up to an earlier
point in the installer because of this.
IOW this really must happen inside the installer.
The filesystem (kernel code and user space tools) needs to tolerate
the inevitability of time/date discrepancies. It can complain loudly
when there's confusion, that's fine, but it can't faceplant. I've lost
track of some of those bugs so I don't recall the specifics. But
clearly computers can have a clock battery die, or even some hardware
has no clock battery, and the idea such a system now can't boot, or
will behave weirdly is not OK, that's a bug.
Meanwhile over on Windows and macOS since time long ago, the installer
environment doesn't have a way to set time or timezone. Those
installers may have a time check and tolerance, I'd sooner expect a
complaint about invalid signing certificate since the payload/packages
are signed. Both OS's do time/date and timezone configuration
Anyway, point is, I don't accept the assumption that the user must be
troubled by this during OS installation. The installer could ensure
hwclock time is the same or after install media's superblock time, and
change it if it's not, and avoid bothering the user with this at this
stage where a lot of hardware does not and will not have an internet
connection for setting the time exactly anyway.