On Mon, Apr 27, 2015 at 6:54 AM, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > 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: None of what you wrote explains a.) Why RTC in local works fine on Windows; b.) why two users in this thread, including the original poster, had problems with a stable timezone set. I don't know about Felix's hardware, but in my case it was UEFI hardware, so RTC in local time does also include timezone and daylight time status. > - 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. Since day 1 NTFS encodes time as UTC. It's really only the RTC that's expected to be in local time and the reason claimed is that users freak out when they go exploring in BIOS configuration and see time other than wall clock time (local time). FAT meanwhile is expected to be encoded in local time, while also lacking any sort of timezone field so all bets are off (at least forensically, at which point why does anyone really care?) > 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.] Seeing as NTFS and HFS+ since ancient times encode timestamps in UTC, I'm flummoxed that this may not be the case on Linux distros for the past 20 years? Really? The filesystem timestamp could be local time? If so, that's hilarious. > 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. Hindsight being 20/20, obviously around 13 years ago Linux (and friends) should have agreed to not fight the RTC being in local time on multiboot systems, in particular dual boot ones with Windows. Windows figures out what timezone the RTC is in by reading the registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation which a Linux OS service could also defer to by default rather than the adversarial relationship that's been chosen. -- Chris Murphy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
