Must set CMOS clock to localtime (due to DOS dual boot), timedatectl or hwclock seems to keep setting CMOS (hardware) clock to UTC!

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












-1















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)



I've told timedatectl that the CMOS clock is in local time.



/etc/default/rcS says:



 UTC=no


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!)










share|improve this question
























  • My current attempt is to have a new init.d script, clockhack, which says: service ntp restart ; hwclock --systohc --localtime, and which is used to create /etc/rc0.d/S00clockhack, /etc/rc6.d/S00clockhack, and /etc/rc6.d/S89clockhack. This at first seemed to work, but now I'm not so sure. Will update in the next day or so as 'time passes'.

    – RustyCar
    Feb 8 '16 at 20:50
















-1















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)



I've told timedatectl that the CMOS clock is in local time.



/etc/default/rcS says:



 UTC=no


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!)










share|improve this question
























  • My current attempt is to have a new init.d script, clockhack, which says: service ntp restart ; hwclock --systohc --localtime, and which is used to create /etc/rc0.d/S00clockhack, /etc/rc6.d/S00clockhack, and /etc/rc6.d/S89clockhack. This at first seemed to work, but now I'm not so sure. Will update in the next day or so as 'time passes'.

    – RustyCar
    Feb 8 '16 at 20:50














-1












-1








-1


1






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)



I've told timedatectl that the CMOS clock is in local time.



/etc/default/rcS says:



 UTC=no


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!)










share|improve this question
















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)



I've told timedatectl that the CMOS clock is in local time.



/etc/default/rcS says:



 UTC=no


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!)







time






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 30 at 21:51









Kusalananda

131k17249409




131k17249409










asked Feb 4 '16 at 19:29









RustyCarRustyCar

343




343












  • My current attempt is to have a new init.d script, clockhack, which says: service ntp restart ; hwclock --systohc --localtime, and which is used to create /etc/rc0.d/S00clockhack, /etc/rc6.d/S00clockhack, and /etc/rc6.d/S89clockhack. This at first seemed to work, but now I'm not so sure. Will update in the next day or so as 'time passes'.

    – RustyCar
    Feb 8 '16 at 20:50


















  • My current attempt is to have a new init.d script, clockhack, which says: service ntp restart ; hwclock --systohc --localtime, and which is used to create /etc/rc0.d/S00clockhack, /etc/rc6.d/S00clockhack, and /etc/rc6.d/S89clockhack. This at first seemed to work, but now I'm not so sure. Will update in the next day or so as 'time passes'.

    – RustyCar
    Feb 8 '16 at 20:50

















My current attempt is to have a new init.d script, clockhack, which says: service ntp restart ; hwclock --systohc --localtime, and which is used to create /etc/rc0.d/S00clockhack, /etc/rc6.d/S00clockhack, and /etc/rc6.d/S89clockhack. This at first seemed to work, but now I'm not so sure. Will update in the next day or so as 'time passes'.

– RustyCar
Feb 8 '16 at 20:50






My current attempt is to have a new init.d script, clockhack, which says: service ntp restart ; hwclock --systohc --localtime, and which is used to create /etc/rc0.d/S00clockhack, /etc/rc6.d/S00clockhack, and /etc/rc6.d/S89clockhack. This at first seemed to work, but now I'm not so sure. Will update in the next day or so as 'time passes'.

– RustyCar
Feb 8 '16 at 20:50











2 Answers
2






active

oldest

votes


















0














man datetimectl is helpful



two steps:




  • timedatectl set-local-rtc 1 --> set the CMOS to local time


  • sudo hwclock --systohc --> copy the local time to CMOS clock





share|improve this answer
































    0














    Ok, first off, I don't understand why I got downvoted for this question.



    In any case, I finally, what 3 years later, found the solution:



    Make sure /etc/adjtime has 'LOCAL' and not 'UTC' (in my case, it was the last line of the file).



    Make sure /etc/hardwareclock has 'localtime' in it (in my case, this was a new file and only had that line in it).



    Doing the above seems to have turned off the 'NTP synch' flag in the kernel, which keeps the kernel from writing the UTC time into the CMOS clock upon shutdown. So it is highly likely that the kernel won't save the system time in the CMOS clock (I've not verified this). However, the above 2 changes appear to have turned off '11-minute mode'.



    Here's the output of 'timedatectl':



    rusty@quigon2 ~ $ timedatectl
    Local time: Wed 2019-01-30 14:18:53 MST
    Universal time: Wed 2019-01-30 21:18:53 UTC
    RTC time: Wed 2019-01-30 14:18:50
    Time zone: America/Phoenix (MST, -0700)
    Network time on: yes
    NTP synchronized: no
    RTC in local TZ: yes

    Warning: The system is configured to read the RTC time in the local time zone.
    ...blah blah...


    (Note the 'NTP synchronized' info above).



    If you want to synchronize with NTP (via ntpd or rdate or whatever), that's a different story. (I used a cron job to rdate and hwclock --systohc every 30 minutes...)



    There is a chance that running timedatectl with some specific options may perform the above changes to the above files, I've not tested that.






    share|improve this answer























    • Accept this answer when you're able to (instead of marking the question as solved by changing its title).

      – Kusalananda
      Jan 30 at 21:52










    Your Answer








    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f259927%2fmust-set-cmos-clock-to-localtime-due-to-dos-dual-boot-timedatectl-or-hwclock%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    man datetimectl is helpful



    two steps:




    • timedatectl set-local-rtc 1 --> set the CMOS to local time


    • sudo hwclock --systohc --> copy the local time to CMOS clock





    share|improve this answer





























      0














      man datetimectl is helpful



      two steps:




      • timedatectl set-local-rtc 1 --> set the CMOS to local time


      • sudo hwclock --systohc --> copy the local time to CMOS clock





      share|improve this answer



























        0












        0








        0







        man datetimectl is helpful



        two steps:




        • timedatectl set-local-rtc 1 --> set the CMOS to local time


        • sudo hwclock --systohc --> copy the local time to CMOS clock





        share|improve this answer















        man datetimectl is helpful



        two steps:




        • timedatectl set-local-rtc 1 --> set the CMOS to local time


        • sudo hwclock --systohc --> copy the local time to CMOS clock






        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Oct 23 '16 at 7:58









        techraf

        4,233102242




        4,233102242










        answered Oct 23 '16 at 7:25









        user196563user196563

        1




        1























            0














            Ok, first off, I don't understand why I got downvoted for this question.



            In any case, I finally, what 3 years later, found the solution:



            Make sure /etc/adjtime has 'LOCAL' and not 'UTC' (in my case, it was the last line of the file).



            Make sure /etc/hardwareclock has 'localtime' in it (in my case, this was a new file and only had that line in it).



            Doing the above seems to have turned off the 'NTP synch' flag in the kernel, which keeps the kernel from writing the UTC time into the CMOS clock upon shutdown. So it is highly likely that the kernel won't save the system time in the CMOS clock (I've not verified this). However, the above 2 changes appear to have turned off '11-minute mode'.



            Here's the output of 'timedatectl':



            rusty@quigon2 ~ $ timedatectl
            Local time: Wed 2019-01-30 14:18:53 MST
            Universal time: Wed 2019-01-30 21:18:53 UTC
            RTC time: Wed 2019-01-30 14:18:50
            Time zone: America/Phoenix (MST, -0700)
            Network time on: yes
            NTP synchronized: no
            RTC in local TZ: yes

            Warning: The system is configured to read the RTC time in the local time zone.
            ...blah blah...


            (Note the 'NTP synchronized' info above).



            If you want to synchronize with NTP (via ntpd or rdate or whatever), that's a different story. (I used a cron job to rdate and hwclock --systohc every 30 minutes...)



            There is a chance that running timedatectl with some specific options may perform the above changes to the above files, I've not tested that.






            share|improve this answer























            • Accept this answer when you're able to (instead of marking the question as solved by changing its title).

              – Kusalananda
              Jan 30 at 21:52















            0














            Ok, first off, I don't understand why I got downvoted for this question.



            In any case, I finally, what 3 years later, found the solution:



            Make sure /etc/adjtime has 'LOCAL' and not 'UTC' (in my case, it was the last line of the file).



            Make sure /etc/hardwareclock has 'localtime' in it (in my case, this was a new file and only had that line in it).



            Doing the above seems to have turned off the 'NTP synch' flag in the kernel, which keeps the kernel from writing the UTC time into the CMOS clock upon shutdown. So it is highly likely that the kernel won't save the system time in the CMOS clock (I've not verified this). However, the above 2 changes appear to have turned off '11-minute mode'.



            Here's the output of 'timedatectl':



            rusty@quigon2 ~ $ timedatectl
            Local time: Wed 2019-01-30 14:18:53 MST
            Universal time: Wed 2019-01-30 21:18:53 UTC
            RTC time: Wed 2019-01-30 14:18:50
            Time zone: America/Phoenix (MST, -0700)
            Network time on: yes
            NTP synchronized: no
            RTC in local TZ: yes

            Warning: The system is configured to read the RTC time in the local time zone.
            ...blah blah...


            (Note the 'NTP synchronized' info above).



            If you want to synchronize with NTP (via ntpd or rdate or whatever), that's a different story. (I used a cron job to rdate and hwclock --systohc every 30 minutes...)



            There is a chance that running timedatectl with some specific options may perform the above changes to the above files, I've not tested that.






            share|improve this answer























            • Accept this answer when you're able to (instead of marking the question as solved by changing its title).

              – Kusalananda
              Jan 30 at 21:52













            0












            0








            0







            Ok, first off, I don't understand why I got downvoted for this question.



            In any case, I finally, what 3 years later, found the solution:



            Make sure /etc/adjtime has 'LOCAL' and not 'UTC' (in my case, it was the last line of the file).



            Make sure /etc/hardwareclock has 'localtime' in it (in my case, this was a new file and only had that line in it).



            Doing the above seems to have turned off the 'NTP synch' flag in the kernel, which keeps the kernel from writing the UTC time into the CMOS clock upon shutdown. So it is highly likely that the kernel won't save the system time in the CMOS clock (I've not verified this). However, the above 2 changes appear to have turned off '11-minute mode'.



            Here's the output of 'timedatectl':



            rusty@quigon2 ~ $ timedatectl
            Local time: Wed 2019-01-30 14:18:53 MST
            Universal time: Wed 2019-01-30 21:18:53 UTC
            RTC time: Wed 2019-01-30 14:18:50
            Time zone: America/Phoenix (MST, -0700)
            Network time on: yes
            NTP synchronized: no
            RTC in local TZ: yes

            Warning: The system is configured to read the RTC time in the local time zone.
            ...blah blah...


            (Note the 'NTP synchronized' info above).



            If you want to synchronize with NTP (via ntpd or rdate or whatever), that's a different story. (I used a cron job to rdate and hwclock --systohc every 30 minutes...)



            There is a chance that running timedatectl with some specific options may perform the above changes to the above files, I've not tested that.






            share|improve this answer













            Ok, first off, I don't understand why I got downvoted for this question.



            In any case, I finally, what 3 years later, found the solution:



            Make sure /etc/adjtime has 'LOCAL' and not 'UTC' (in my case, it was the last line of the file).



            Make sure /etc/hardwareclock has 'localtime' in it (in my case, this was a new file and only had that line in it).



            Doing the above seems to have turned off the 'NTP synch' flag in the kernel, which keeps the kernel from writing the UTC time into the CMOS clock upon shutdown. So it is highly likely that the kernel won't save the system time in the CMOS clock (I've not verified this). However, the above 2 changes appear to have turned off '11-minute mode'.



            Here's the output of 'timedatectl':



            rusty@quigon2 ~ $ timedatectl
            Local time: Wed 2019-01-30 14:18:53 MST
            Universal time: Wed 2019-01-30 21:18:53 UTC
            RTC time: Wed 2019-01-30 14:18:50
            Time zone: America/Phoenix (MST, -0700)
            Network time on: yes
            NTP synchronized: no
            RTC in local TZ: yes

            Warning: The system is configured to read the RTC time in the local time zone.
            ...blah blah...


            (Note the 'NTP synchronized' info above).



            If you want to synchronize with NTP (via ntpd or rdate or whatever), that's a different story. (I used a cron job to rdate and hwclock --systohc every 30 minutes...)



            There is a chance that running timedatectl with some specific options may perform the above changes to the above files, I've not tested that.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Jan 30 at 21:46









            RustyCarRustyCar

            343




            343












            • Accept this answer when you're able to (instead of marking the question as solved by changing its title).

              – Kusalananda
              Jan 30 at 21:52

















            • Accept this answer when you're able to (instead of marking the question as solved by changing its title).

              – Kusalananda
              Jan 30 at 21:52
















            Accept this answer when you're able to (instead of marking the question as solved by changing its title).

            – Kusalananda
            Jan 30 at 21:52





            Accept this answer when you're able to (instead of marking the question as solved by changing its title).

            – Kusalananda
            Jan 30 at 21:52

















            draft saved

            draft discarded
















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f259927%2fmust-set-cmos-clock-to-localtime-due-to-dos-dual-boot-timedatectl-or-hwclock%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown






            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?