This is beyond crazy.
I have a dual-boot system, one OS is FreeDOS (which has NO ability to deal with CMOS clock being anything other than local time), and the other is Linux Mint 17.
The way this system is used is that we sit in Linux waiting for a 'trigger' (software trigger) to start testing. The testing is done under FreeDOS, so the scripts set everything up while in Linux, then set the system to boot FreeDOS and run the test then reboot back to Linux. This happens anywhere from once every few minutes to once every few days.
We have noticed that sometimes the clock gets COMPLETELY messed up. It appears that we get in to a cycle of 'set the CMOS clock to UTC; load CMOS clock assuming it is localtime (bam, 8 hours ahead); set the CMOS clock to UTC (adding ANOTHER 8 hours!!!); repeat'.
It is an absolute requirement (well, absolutely desired) that the clock be right, in both systems, regardless of how often or rarely we boot from one to the other.
I have NTP set up on the Linux side, and it works fine usually.
Apparently I'm in 11-minute mode.
Here is what happens after setting the hw (CMOS) clock to localtime, then waiting 11 minutes and looking again:
tjr2pc1 ~ # date ;timedatectl status ; sleep 660 ; date;timedatectl status Thu Feb 4 12:03:33 MST 2016 Local time: Thu 2016-02-04 12:03:33 MST Universal time: Thu 2016-02-04 19:03:33 UTC RTC time: **Thu 2016-02-04 12:03:33** Timezone: America/Phoenix (MST, -0700) NTP enabled: yes NTP synchronized: yes RTC in local TZ: yes DST active: n/a Warning: The RTC is configured to maintain time in the local time zone. This mode is not fully supported and will create various problems with time zone changes and daylight saving adjustments. If at all possible use RTC in UTC, by calling 'timedatectl set-local-rtc 0'. Thu Feb 4 12:14:33 MST 2016 Local time: Thu 2016-02-04 12:14:33 MST Universal time: Thu 2016-02-04 19:14:33 UTC RTC time: **Thu 2016-02-04 19:14:33** Timezone: America/Phoenix (MST, -0700) NTP enabled: yes NTP synchronized: yes RTC in local TZ: yes DST active: n/a -----------------
Note that the CMOS clock is suddenly in UTC time! ****PLEASE MAKE IT STOP***
I even tried installing fake-hwclock, this still happens. I even renamed /sbin/hwclock to /sbin/real_hwclock in an attempt to make the kernel just leave the blasted CMOS alone.
To review: The goal is to make time work in both FreeDOS and Linux.
I don't care if that means that Linux sets the CMOS clock to UTC and then restores it to local time upon shutdown, or if I can somehow force Linux to set it to localtime instead of UTC. Or if I can get Linux to totally ignore the CMOS clock (that's why I installed fake_hwclock - I was hoping that would do it. Nope). I don't care HOW, I just need the CMOS clock to be set to the correct local time once Linux has shut down (so that FreeDOS gets the correct time). (For reasons too involved to bother you all with, it isn't possible to run networking under FreeDOS so I can use ntp or a script or something to automatically set the time correctly there. And making the 'go to FreeDOS script write a script to set the time and date under FreeDOS is stupid, but I'm about to do it just to stop fighting the stupidity)
timedatectl that the CMOS clock is in local time.
And yet every 11 minutes somebody (the kernel, I assume) sets the CMOS clock to the UTC time! Even though I explicitly said it is supposed to be local time.
And, yes, I've rebooted (multiple times) since setting rcS to say UTC=no. Is there yet another config file somewhere to get the kernel to either leave the CMOS clock alone, or to force it to set it to local time?
Update: I've found some interesting things w.r.t. "11-minute mode", including a question on reddit that talks about this very thing, and blames ntp and adjtimex (internal to the kernel, not the executable). No solution yet, and I'm about to just write a cron job that runs every minute and forces the hw clock back to local time. (I hate using a sledgehammer like that, but I really need the time to be correct - asap, as our clocks are getting completely messed up (one computer's time is over 12 hours slow (weird), one is 7 hours fast, and one is almost a day and a half ahead! Just from Friday to Monday!)