Here's the pertinent text from
man hwclock:
Code:
LOCAL vs UTC
Keeping the Hardware Clock in a local timescale causes inconsistent daylight saving time results:
If Linux is running during a daylight saving time change, the time written to the Hardware Clock
will be adjusted for the change.
If Linux is NOT running during a daylight saving time change, the time read from the Hardware Clock
will NOT be adjusted for the change.
The Hardware Clock on an ISA compatible system keeps only a date and time, it has no concept of time-
zone nor daylight saving. Therefore, when hwclock is told that it is in local time, it assumes it is
in the 'correct' local time and makes no adjustments to the time read from it.
Linux handles daylight saving time changes transparently only when the Hardware Clock is kept in the
UTC timescale. Doing so is made easy for system administrators as hwclock uses local time for its
output and as the argument to the --date option.
POSIX systems, like Linux, are designed to have the System Clock operate in the UTC timescale. The
Hardware Clock's purpose is to initialize the System Clock, so also keeping it in UTC makes sense.
Linux does, however, attempt to accommodate the Hardware Clock being in the local timescale. This is
primarily for dual-booting with older versions of MS Windows. From Windows 7 on, the RealTimeIsUni-
versal registry key is supposed to be working properly so that its Hardware Clock can be kept in UTC.
I don't see any mention of UTC being better on a dual boot. What it does say is that it only takes into account DST if the system is running at the time.
So, if you are one to keep your computer turned off overnight (when DST changes happen), it would be better to keep it in UTC, as the system will auto adjust to DST when it is turned back on, or ensure time synchronization is set up (which you should have set up regardless). But if a system using localtime on the hardware clock is running (either Windows, Linux, or something else) and that system changes the DST and updates the hardware clock, any other system that is booted up afterwards will be perfectly fine and not need to make any adjustments.
That is likely why I never ran into issues with the clock not being in sync after DST... my computer was always on, either in Windows or Slackware. When whatever system was booted during DST was shutdown, that updated time was saved to the hardware clock and read in the other system as the correct time (which it was).
Yes, UTC does prevent timezone issues (assuming the timezone is set right on the OS), but keeping the hardware clock on localtime is not the doom and gloom you spell it out to be. Simply put, it is really easy to adjust Slackware to use a localtime hardware clock, but Windows requires a registry edit (not so easy). If the system is off when DST happens, but has time synchronization set up, then the problem is pretty much non-existent except for the short period of time between startup and syncing (and if that short period of time is really important because of logging, then you likely aren't dual booting or turning your system off during DST -- and for those types of systems, UTC would be better).
I'm not saying that UTC isn't preferred, but if a home user wants to keep their system on localtime to simplify things, there's nothing wrong with that. I stand by my suggestion to wirelessmc to use localtime on their system since they were having a difficult time understanding what was going on.
