[Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again

[Zbigniew Jędrzejewski-Szmek]

On Sun, Apr 26, 2015 at 11:47:18PM -0600, Chris Murphy wrote:
> Time in UTC is just as absurd and arbitrary as time in a local
> timezone,
No, it's not. This has been written about many times, but in short:
- the information about the timezone used is not stored in RTC,
  so all users of RTC need to be configured to use the same timezone
  externally
- the offset that was actually used when setting RTC is not stored,
  so around the DST transitions, there's no way to know if the clock
  was already updated or not.

When we all had nice big tower computers, this wasn't as much of a
problem: a machine could spend its entire useful life in the same
timezone. But now people lug their laptops around, and even expect
the timezone to be updated automatically from geoinfo.

In this specific case, the problem is that the *initramfs* needs an
up-to-date copy of this information. We used to check the root
filesystem after mounting it read-only. Now we check filestems either
in the kernel (btrfs, xfs), or from the initramfs (ext[234] and most
others). This makes the checking more robust, but it means that we
need timezone info even earlier if RTC is in localtime.

In this specific case, not only all systems in the multi-boot setup,
but also the *initramfs* needs an up-to-date copy of this
information. So first, your generic initramfs distributed with the
system cannot be used anymore, and second, you need to rewrite your
initramfs'es when you change the timezone.

A very similar issue happens with portable storage devices: if you
store timestamps as localtime on them, when you move them to a
different machine, there's no way to know if the same timezone (and in
the same DST phase) was used. We are starting to follow Android here,
and using UTC timestamps instead, and only doing conversions locally.
[This is a tradeoff: we pick to display the information about how long
ago the file was written (e.g. 2 days, 3 hours, 5 minutes ago), and
possibly lose the information what the clock was displaying at the
time (e.g. 11:05). In *some* circumstances the second would be useful too,
but in majority of cases the first is what we actually care about.]

We could try to build an infrastructure to store tz information, and
rebuild initramfses, etc, or we can just rip of the bandaid. This is a
game of whack-a-mole which accelerates are systems get more dynamic
and mobile that we cannot really hope to win.

Zbyszek

> so if Windows is going to get berated for not dealing with
> UTC properly, then Fedora can be berated for not dealing with local
> time properly.