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@xxxxxxxxxx> http://karelzak.blogspot.com -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html