Bug 134464
| Summary: | Daylight saving doesnot synchronize hardware clock with system clock | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Sameh Attia <sattia> |
| Component: | initscripts | Assignee: | Bill Nottingham <notting> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | CC: | rvokal |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-10-05 15:42:14 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
First of all, this has nothing to do with tzdata, that is a package containing just the timezone data files and nothing else. What you should be doing is use ntpd which will take care of keeping your time synchronized at all times. If you for some reason don't want that, you should use UTC for hardware clock, that way it doesn't need any adjustements when daylight saving occurs. Otherwise, /etc/rc.d/init.d/halt script during reboot sets hardware clock to the system time. If your system crashes or looses power, you need to set up proper time manually and /sbin/hwclock --systohc --localtime If your system is not using ntpd and doesn't have UTC hw clock, there is nothing the system can do for you so that you don't need to change clock manually if it lost power in the session in which daylight saving change occured - how could the system know if hw clock is a time still in the old daylight saving mode or new one? First, I would like to thank u 4 ur quick response. Now, I didnt know exactly whats the package to choose, and found that tzdata is the most close choice. Yes for sure we use NTP, but imagine when the machine crashes and rebooted and the hardware clock is an hour -/+ from the correct time. Do u know how much time needed to synchronize an hour? and most times crashes happen renders the ntpd malfunctioning and user intervention is required. A stale lock file or something like that around. We are trying to minimize the manual intervention required and to make linux as reliable as possible. NTP service has ntpdate command, which works before the ntpd daemon and SETS the time to the exact correct time. The clock is saved to the hardware clock a) at the time of setting it b) at shutdown. I don't think saving it periodically in the background is worth the effort in this case. Bill, I didnt ask to set it periodically. Set it at the same time u when change to the new daylight saving time. You already do this; so it wont harm to add this. Or show me where u do it and I can do it myself. The time change is 'done' in libc, and as Jakub stated above, there are not going to be changes in libc to call hwclock. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040923 Description of problem: On daylight savings, if the machine crashed due to any reasons the hwclock will not be syncronized to the correct new time. Version-Release number of selected component (if applicable): All How reproducible: Always Steps to Reproduce: 1. Choose any country from timeconfig 2. Set the date to the time on which a dayligh saving will occur 3. Wait till the saving happens 4. Cut the power 5. Power up the machine and u should find the old time not the new one Actual Results: An incorrect time Expected Results: Correct new time according to the time saving rules Additional info: