On Wed, Jul 5, 2017 at 2:31 AM, Hans de Goede <hdegoede(a)redhat.com> wrote:
The problem is with freshly generated files, if the timezone is say
CET, then those files (and also the filesystem creation timestamp in
the superblock) get created at UTC+1, if then after boot the user corrects
the timezone to say UTC-6 and within those 7 hours reboots the user
will get a bunch of complaints from fsck and other tools about timestamps
in the future. IIRC. esp. the fsck issue was nasty.
Really this is a solved problem for 8 years or so now, the anaconda team
has gone over this in much detail back then. We simply MUST ask for the
timezone info before writing anything to disk.
*shrug* considering 90% of the rest of the world's in-use OS's do not
have this requirement or problem, to me it sounds like a bug. I'll add
it to my test list and see what really breaks still but I think this
is specious logic at play. And in fact fsck shouldn't be run
automatically anyway these days, it's archaic. Ext4, XFS, and Btrfs do
log replay at mount time when needed.
And in any case, the timezone information is available via GetTime()
from UEFI runtime services, but the installer not only does not use
this information, still badgering the user for it, it then proceeds to
overwrite the TimeZone information with UTC instead, without the
user's knowledge or permission. That's very clearly data loss and
creates the very condition of timezone ambiguity we had on BIOS
firmware machines, that was supposed to be fixed with UEFI.
So in effect, we not only fail to ignore the UEFI spec for no
technical reason, trouble the user for this information unnecessarily,
we further proceed to sabotaging the attempt to make device time and
location unambiguous. Time itself remains unambiguous when TimeZone is
set to UTC, but now the data indicting purported physical location of
the device is lost.