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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
