Re: Discussion on BIOS/CMOS/UEFI clock in local time

[Karel Zak <kzak@redhat.com>]

On Thu, Feb 14, 2013 at 01:30:47PM +0100, Dr. Werner Fink wrote:
> just before such a discussion I'd like to point the mail
> 
>      https://lkml.org/lkml/2008/1/12/87
> 
> from Ted Ts'o in the mail thread
> 
>      https://lkml.org/lkml/2008/1/8/195
> 
> In this mail he advises to set set the system clock before running
> e2fsck on an ext3 and higher file system to avoid wrong timestamps.
> 
> As this problem can also occur with other journaling file systems
> the way to avoid this is to correct the kernels assumption that the
> BIOS/CMOS clock is running in UTC by using the the system call
> settimeofday(2) with the tz_minuteswest field of the timezone
> structure.
> 
> This may done with the hwclock option --systz or here with the
> small warpclock utility in the initrd/initramfs.  Now with the UEFI
> specs (section 7.3) the local time will become more often the default
> for the BIOS/CMOS clock.
> 
> This will raise twice a year the problem if or if the HW clock has
> been corrected for DST on/off by the user or an other OS like Windows[tm].
> First case requires to ask the user if or if the DST offset has been
> corrected.  Whereas in the second case I do not know where the other
> OS stores its information about DST on/off.
> 
> With UEFI this could be solved as the EFI BIOS shows DST and TIMEZONE
> entries.  But AFAICS from the kernels source (3.7) the timezone is
> simply ignored, compare with drivers/rtc/rtc-efi.c as well as with
> drivers/char/efirtc.c in the functions convert_to_efi_time() and
> convert_from_efi_time() ...  also for the user space tools there
> is no API to change e.g. the DST flag.

 That's cool news. Thanks.

 It seems that kernel CONFIG_RTC_HCTOSYS code should be improved to use
 the information from UEFI rather than blindly assume that HW clock is 
 always in UTC. I don't see a reason to try to fix this in userspace as
 we use (or we want:-) CONFIG_RTC_HCTOSYS almost everywhere.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com