http://bugzilla.novell.com/show_bug.cgi?id=595573 http://bugzilla.novell.com/show_bug.cgi?id=595573#c yang xiaoyu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xyyang@novell.com AssignedTo|bnc-team-screening@forge.pr |nfbrown@novell.com |ovo.novell.com | -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=595573 http://bugzilla.novell.com/show_bug.cgi?id=595573#c2 Ruediger Oertel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |werner@novell.com --- Comment #2 from Ruediger Oertel 2010-05-17 14:06:32 UTC --- werner: is that to be expected? what should happen with the bios clock if this is configured for "--localtime" ? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=595573 http://bugzilla.novell.com/show_bug.cgi?id=595573#c4 --- Comment #4 from Geoff Farrell 2010-05-24 05:07:11 UTC --- I don't think I've ever come across such muddled thinking.

If CMOS is localtime it is up to the user to change the CMOS time.

Why? When the system startup has gone to the trouble of correcting to the new local time, why can't it simply be saved to CMOS on shutdown, as it's supposed to happen with boot.clock (under the 'stop' stanza)? The bug here is that the time was changed to the correct time according to timezone settings for Australia/Sydney, but the time was not saved to the Hardware Clock on shutdown as it was supposed to, by obeying the SYSTOHC="yes" setting in /etc/sysconfig/clock.

There is no point to save the information that the switch from/to Daylight Saving Time within the CMOS.

??? The point is to change the local time to the correct local time, as has been specified in /etc/sysconfig/clock: ie, --localtime.

Doing this on disk will not work... (1)

It's not done on disk; the time is supposed to be saved to CMOS memory on the motherboard.

...as normally only users with several OS (e.g. Windows[tm]) do use localtime in CMOS. (2)

Not true. I only use openSUSE; it's the only OS installed. I don't know of anyone in Australia that uses UTC in their Hardware (CMOS) Clock, regardless of whether they use Linux, Windows, Mac, or anything else. Local time is used, because that's the easiest time to refer to. Points (1) and (2) are unrelated. Therefore, (2) does not follow from (1).

If Linux is the only OS on the system the user is strongly enforced to use the common standard for CMOS wich is UTC.

Is 'enforced' the intended meaning here? Or was 'encouraged' really meant? Regardless, my openSUSE system works well with the Hardware Clock set to my local time zone. That's not surprising, given the effort made in accommodating this sort of setting in system configuration files, such as HWCLOCK="--localtime" and TIMEZONE="Australia/Sydney" in /etc/sysconfig/clock. What's the point of having these provisions if there is simply an ideological position that UTC should be used instead? There's nothing special about UTC. It can be derived from simple mathematics using local time and the TIMEZONE setting (openSUSE obviously performs this quite competently at the moment). This issue has nothing to do with UTC. It has everything to do with a shutdown script (boot.clock) failing to do its job. FWIW, I use local time in my Hardware Clock because UTC is more difficult for humans to relate to in +10- and +11-hour timezones. I would much prefer my computer to handle that for me. One of the reasons I own a computer is for it to do computations for me, not the other way around. In summary, the startup system correctly applied the adjustment to local time for the System Clock at the end of daylight saving, but the system failed to obey the /etc/sysconfig/clock settings to save the correct time to the Hardware Clock. That's a bug, pure and simple. I request that this bug be reopened and addressed. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=595573 http://bugzilla.novell.com/show_bug.cgi?id=595573#c6 --- Comment #6 from Geoff Farrell 2010-06-26 00:22:52 UTC --- Werner, thank you for the detailed explanation of the problems associated with Daylight Saving Time (DST) and Hardware Clocks. I appreciate that that would have taken a good deal of your time. I have examined this problem and think I have a solution. It is based on asking the user what s/he wants to do about it - whether to automatically change the Hardware Clock at DST transition or not. The user could based their decision on whether another OS occupies the hard disk in a dual-boot situation. In my case, without another OS, I would answer 'yes'; someone with another OS which might change the time at DST transition would be best advised to answer 'no'. To achieve this, I suggest putting an option 'AUTODST' into /etc/sysconfig/clock, which would have a yes/no setting. Then it would need code in initrd to examine whether a DST transition has occurred, and to change the System Clock when it happens, then write the time back to the Hardware Clock before proceeding with mounting the real '/' filesystem. This 'AUTODST' setting would also need to be in initrd, along with the current 'HWCLOCK=' setting. The major difficulty with this method - as you have pointed out - is that the hardware does not support the setting of such a flag, and neither is the filesystem available at that point in the bootup sequence to retrieve it. However, I was able to institute a system where the status of Daylight Saving (DSTstatus) - whether active or not - is saved on an unused sector of the boot disk (I used sector 62 because it was far away from the preceding mbr boot code), and 'dd' is used to read from or write to that sector to extract the DSTstatus information. The code (checkDSTstatus) then examines the /etc/localtime file (already in initrd), calculates the DST transition points, then determines whether the current time at bootup has passed a DST transition point. If so, then action can be taken there and then (by a modified 05-clock.sh) before the bootup sequence moves on to mount the real '/' filesystem. This code needs a few more commands in initrd to run the calculations. My method would require the installer (and YaST-> System-> Bootloader after the system has been installed) to provide an option in the Timezone setting screen called 'Automatically change the Hardware Clock at Daylight Saving Time transition'. This option would only be enabled when a user disables the 'Hardware Clock Set To UTC' option. Enabling this option would set the 'AUTODST' flag in /etc/sysconfig/clock to 'yes'. The help information for this option would caution enabling this option in a dual-boot situation. The Bootloader would also need to save the DSTstatus to Sector 62 of the boot device, and record the device name (eg, /dev/sda) in another file /etc/sysconfig/bootdevice (also required in initrd) Another file would be required in initrd (/etc/sysconfig/DSTchange) to record the result of checkDSTstatus. I will attach the files required to achieve all of this. They are: To be contained within initrd: /etc/sysconfig/DSTstatus /etc/sysconfig/DSTchange /etc/sysconfig/bootdevice /etc/sysconfig/clock /bin/checkDSTstatus /boot/05-clock.sh (modified version - same as /etc/init.d/boot.dstclock) These are not attached (as they are normal system files) but are required to be in initrd: /bin/dd /bin/head /bin/tail To be contained in the normal filesystem: /bin/checkDSTstatus (same as in initrd) /etc/init.d/boot.dstclock (same as 05-clock.sh in initrd) To test the functioning of the two scripts above, I unpacked initrd, added the files listed above to be contained within initrd, then re-packed it. I have not looked at the task of modifying mkinitrd to achieve those changes. More detailed explanation of the methodology is contained in the scripts' comments. I will also attach a 'Test' version of checkDSTstatus that was used to check out various timezones, locales and dates, to see that the code operated correctly. This version contains many more 'echo' statements that lets you see what is going on at various stages. The method of storing the DSTstatus flag to a hard-coded boot device sector is crude, but is meant as a demonstrator of the overall method. Maybe a more sophisticated method would be required for production. Since the Bootloader would be the best tool to save the information at installation, perhaps it could add it to the end of the MBR code, from where it could be retrieved by a suitably modified checkDSTstatus script. Thanks for taking the time to consider this. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=595573 http://bugzilla.novell.com/show_bug.cgi?id=595573#c8 --- Comment #8 from Geoff Farrell 2010-06-26 00:26:26 UTC --- Created an attachment (id=371923) --> (http://bugzilla.novell.com/attachment.cgi?id=371923) Script to change the Hardware Clock when determined by checkDSTstatus. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=595573 http://bugzilla.novell.com/show_bug.cgi?id=595573#c10 --- Comment #10 from Geoff Farrell 2010-06-26 00:28:25 UTC --- Created an attachment (id=371926) --> (http://bugzilla.novell.com/attachment.cgi?id=371926) Config file in /etc/sysconfig, used to store the result of checkDSTstatus script. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=595573 http://bugzilla.novell.com/show_bug.cgi?id=595573#c12 --- Comment #12 from Geoff Farrell 2010-06-26 00:31:10 UTC --- Created an attachment (id=371928) --> (http://bugzilla.novell.com/attachment.cgi?id=371928) Config file in /etc/sysconfig, has an additional 'yes/no' flag called 'AUTODST'. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=595573 http://bugzilla.novell.com/show_bug.cgi?id=595573#c14 --- Comment #14 from Geoff Farrell 2010-06-26 00:33:17 UTC --- Created an attachment (id=371930) --> (http://bugzilla.novell.com/attachment.cgi?id=371930) Version of checkDSTstatus used to test the methodology of detecting when a DST transition point has occurred. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=595573 http://bugzilla.novell.com/show_bug.cgi?id=595573#c16 --- Comment #16 from Geoff Farrell 2010-07-09 04:45:38 UTC --- I have developed a new method of changing the Daylight Saving time that does not involve storing the status of Daylight Saving on a physical hard disk sector. Instead, it stores the value in /etc/sysconfig/DSTstatus in the initrd environment, which is then exported within the /boot/93-boot.sh script, for use later when /etc/init.d/boot.clock is run in the root filesystem. The DST_CHANGE value is also exported in this way. Both values are stored in their permanent root filesystem locations (/etc/sysconfig/DSTstatus and /etc/sysconfig/DSTchange respectively) within a changed /etc/init.boot script so that the root filesystem knows about the DST status. With this method, the value of /etc/sysconfig/DSTstatus needs to be stored in the same file held within /boot/initrd, so that on the next bootup, the changed status of Daylight Saving is known to the initrd environment. A script (to reside in /bin/changeInitrd) was developed to achieve that. The only downside is that modifying /boot/initrd takes about 5 seconds, which is slower than writing to a hard disk sector. However, since this should only occur twice per year, that is not too much of an imposition. I also standardised the variables DST_CHANGE and DST_STATUS throughout the modified scripts, as the previous usage was inconsistent, and might have been confusing. I will attach the new files for this different method: changeInitrd (/bin/changeInitrd) dstclock (/etc/init.d/dstclock and 05-clock.sh in initrd's 'boot' directory) 93-boot.sh (in initrd's 'boot' directory) boot (/etc/init.d/boot) boot.clock (/etc/init.d/boot.clock) Note that the name of 'dstclock' was changed from 'boot.dstclock' to prevent it being run automatically at bootup along with all the other /etc/init.d/boot.* files. It only needs to be called by /etc/init.d/boot.clock. The checkDSTstatus file and /etc/sysconfig/clock (plus its version in initrd), posted previously, are unchanged. /etc/sysconfig/bootdevice is no longer needed. As well, /bin/dd and /bin/head are no longer required within initrd. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=595573 http://bugzilla.novell.com/show_bug.cgi?id=595573#c18 --- Comment #18 from Geoff Farrell 2010-07-09 04:48:08 UTC --- Created an attachment (id=374765) --> (http://bugzilla.novell.com/attachment.cgi?id=374765) dstclock Script to change the Hardware Clock when determined by checkDSTstatus -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=595573 http://bugzilla.novell.com/show_bug.cgi?id=595573#c20 --- Comment #20 from Geoff Farrell 2010-07-09 04:49:49 UTC --- Created an attachment (id=374767) --> (http://bugzilla.novell.com/attachment.cgi?id=374767) boot Modified version of /etc/init.d/boot that saves the exported variables in the root filesystem -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=595573 http://bugzilla.novell.com/show_bug.cgi?id=595573#c22 --- Comment #22 from Dr. Werner Fink 2010-07-09 11:16:59 UTC --- (In reply to comment #16) .. I like the idea, nevertheless, do you know how this problem is solved within the Windows[tm] world? At which place does this OS store the information of a DST<->NT switch? It would the natural way to use exactly the same place with the same semantic, wouldn't it. Beside this for a Linux only based system it makes no sence to use locatime as reference in the HW/CMOS clock as the kernel its self traditional uses UTC as reference ... see linux/kernel/time.c. Please note that the (g)libc API (with e.g. /etc/localtime) depends on this otherwise you would not be able choose an other (local)time zone by simply changing /etc/localtime with zic(8) nor the automatic switch DST<->NT would work out of the box. AFAIK with Windows7[tm] it is also possible to hold the HW/CMOS clock in UTC ... see http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html search for 2008-10-31 -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.