Clocks going forward

In message , Roderick
Stewart writes:
[]
For the next six months or so I'll have to remember to correct the
time on my computer every time I boot it into Windows after using
Linux. It's not difficult - I just go to the settings page that has
the little switch for "Set time automatically" and follow the
traditional procedure of switching it off and switching it on again -
but I always have to remember to do it, so the sooner this nonsense
ends permanently, the better.

Since it looks unlikely that it will )-:, can't you put a batch file to
do that off-and-then-on-again into your startup folder? I'd be surprised
if there isn't a command line version of "go to the settings page and
.... switching it off and switching it on again". (Crossposted to a
Windows 'group - may not be the right one, don't know which one you're
using - as someone there is likely to know the correct incantations.)

Rod.
John
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Does God believe in people?

On 01/04/2018 13:01, J. P. Gilliver (John) wrote:
In message , Roderick
Stewart writes:
[]
For the next six months or so I'll have to remember to correct the
time on my computer every time I boot it into Windows after using
Linux. It's not difficult - I just go to the settings page that has
the little switch for "Set time automatically" and follow the
traditional procedure of switching it off and switching it on again -
but I always have to remember to do it, so the sooner this nonsense
ends permanently, the better.

I agree. Clock changes are arbitrary, artificial, and give no real
benefit. We did without them for centuries, and could and should do so
again. However ...

Since it looks unlikely that it will )-:, can't you put a batch file to
do that off-and-then-on-again into your startup folder? I'd be surprised
if there isn't a command line version of "go to the settings page and
... switching it off and switching it on again". (Crossposted to a
Windows 'group - may not be the right one, don't know which one you're
using - as someone there is likely to know the correct incantations.)

There's no need, there's a much simpler solution, to set Linux to set
the system real-time-clock (RTC) to local rather than international
time. I can't speak for other distros, but for Ubuntu 16.04, the three
relevant configuration commands that I use are as follows, with the last
being the one that will cure the OP's problem.

timedatectl set-timezone Europe/London # Set UK time zone
timedatectl set-ntp true # Use internet time
timedatectl set-local-rtc true # Set RTC to local time

J. P. Gilliver (John) wrote:
In message , Roderick
Stewart writes:
[]
For the next six months or so I'll have to remember to correct the
time on my computer every time I boot it into Windows after using
Linux. It's not difficult - I just go to the settings page that has
the little switch for "Set time automatically" and follow the
traditional procedure of switching it off and switching it on again -
but I always have to remember to do it, so the sooner this nonsense
ends permanently, the better.

Since it looks unlikely that it will )-:, can't you put a batch file to
do that off-and-then-on-again into your startup folder? I'd be surprised
if there isn't a command line version of "go to the settings page and
... switching it off and switching it on again". (Crossposted to a
Windows 'group - may not be the right one, don't know which one you're
using - as someone there is likely to know the correct incantations.)

Rod.
John

I find it unbelievable that this is necessary.

If you're using LiveCDs for your Linux, then yes,
chaos reigns supreme.

If, however, you have a hard drive installation of
Linux and are dual booting, there is a setting to make
the BIOS storage format of time, compatible with Windows.

https://askubuntu.com/questions/7204...-utc-no-in-etc

https://askubuntu.com/questions/1693.../720466#720466

There might have been a change in behavior when systemd
came along. Requiring a different command.

If you cannot bring the two OSes into agreement, it's a bug.

As for DST behavior, it's programmable too. After my
Win2K stopped receiving updates, you could use a command
on Win2K to manually enter the date when DST change should
happen. While a later OS like WinXP would get a TZ patch
with the details, you could effect the same changes manually
in a minute or two. The application might have been
tzedit or the like.

https://support.microsoft.com/en-us/...dows-operating

I think at the time, back when fixing my Win2K, I got a
copy of tzedit off some server, to do the fix.

https://web.archive.org/web/20080514.../timezone.html

(Picture of tool for manual change...)

https://web.archive.org/web/20070610..._time_zone.jpg

Paul

On Sun, 1 Apr 2018 13:01:42 +0100, "J. P. Gilliver (John)"
wrote:

In message , Roderick
Stewart writes:
[]
For the next six months or so I'll have to remember to correct the
time on my computer every time I boot it into Windows after using
Linux. It's not difficult - I just go to the settings page that has
the little switch for "Set time automatically" and follow the
traditional procedure of switching it off and switching it on again -
but I always have to remember to do it, so the sooner this nonsense
ends permanently, the better.

Since it looks unlikely that it will )-:, can't you put a batch file to
do that off-and-then-on-again into your startup folder? I'd be surprised
if there isn't a command line version of "go to the settings page and
... switching it off and switching it on again". (Crossposted to a
Windows 'group - may not be the right one, don't know which one you're
using - as someone there is likely to know the correct incantations.)

Rod.
John

I use a simple time sync prog called Neutron that will sort out the
time on all my Win machines.. While I haven't had any trouble with
Windows knowing what date the time changes (that was covered in a
patch back when they moved the date) Neutron also syncs the time in my
machines with a NIST server to make them all within a second or so of
each other

J. P. Gilliver (John) wrote:

Roderick Stewart WROTE:

For the next six months or so I'll have to remember to correct the
time on my computer every time I boot it into Windows after using
Linux. It's not difficult - I just go to the settings page that has
the little switch for "Set time automatically" and follow the
traditional procedure of switching it off and switching it on again
- but I always have to remember to do it, so the sooner this
nonsense ends permanently, the better.

Since it looks unlikely that it will )-:, can't you put a batch file
to do that off-and-then-on-again into your startup folder? I'd be
surprised if there isn't a command line version of "go to the
settings page and ... switching it off and switching it on again".
(Crossposted to a Windows 'group - may not be the right one, don't
know which one you're using - as someone there is likely to know the
correct incantations.)

If using an atomic clock utility to sync his computer's time over the
Internet (e.g., NIST) is not an option the he could use the tzutil.exe
command to change the timezone. However, when looking online for
timezone IDs, I didn't see one for "British Summer Time" when I run
"tzutil /l" (you can pipe the stdout into more via "tzutil /l | more".
I'm guessing "GMT Standard Time" or "GMT Standard Time_dstoff" would be
used. Run "tzutil /g" to find out what timezone ID is used on your
computer. "tzutil /?" to get help. Run in a command shell (or, as you
suggest, in a .bat file as a startup item or as a login script).

tzutil.exe is available in Windows 7 (that I'm using) so presumably it
is available in later Windows versions. However, Roderick will have to
check what is the current date to know when summer/winter time offset
occur. His batch file would have to check the date to see if the
current date is between those change days to know which timezone ID to
use with tzutil. Off the top of my head, the batch file would use "for
/f "eol " in (`date`) ...

(be sure to use backquotes to indicate running a command and piping its
output as the input for the 'in' clause. I'd then convert the current
day to the numerical day of the year and check if that was between the
numerical day equivalents for the time offset change days.

http://www.robvanderwoude.com/datetimentparse.php

Anything can be used for the starting varname. In the example above, A
was use. You could use X so the 3 delimited (parsed) args would be X,
Y, and Z. The author (in the linked-to "Basics" article) uses quotes.
I thought you had to use backquotes to run a command to have its stdout
piped into the 'in' clause (the string it will parse).

Probably a lot more work for Roderick to write a batch file to parse the
current date, check if in or outside a date range (for the days when the
clocks move forward/back an hour), and decide which timezone ID to use
in a tzutil command. Easier would get be to get a network time sync
program -- unless his Windows host is a standalone computer.

In message ,
writes:
On Sun, 1 Apr 2018 13:01:42 +0100, "J. P. Gilliver (John)"
wrote:

In message , Roderick
Stewart writes:
[]
For the next six months or so I'll have to remember to correct the
time on my computer every time I boot it into Windows after using
Linux. It's not difficult - I just go to the settings page that has
the little switch for "Set time automatically" and follow the
traditional procedure of switching it off and switching it on again -
but I always have to remember to do it, so the sooner this nonsense
ends permanently, the better.

Since it looks unlikely that it will )-:, can't you put a batch file to
do that off-and-then-on-again into your startup folder? I'd be surprised
if there isn't a command line version of "go to the settings page and
... switching it off and switching it on again". (Crossposted to a
Windows 'group - may not be the right one, don't know which one you're
using - as someone there is likely to know the correct incantations.)

Rod.
John

I use a simple time sync prog called Neutron that will sort out the
time on all my Win machines.. While I haven't had any trouble with
Windows knowing what date the time changes (that was covered in a
patch back when they moved the date) Neutron also syncs the time in my
machines with a NIST server to make them all within a second or so of
each other

My understanding of the problem was that he _wasn't_ having a problem
sorting the time on his Windows machine(s), but that he was dual-booting
one machine in Windows and Linux, and one of those OSs implements DST by
leaving the computer's in-built clock alone and adding an hour to it as
necessary, whereas the other one was actually adjusting the in-built
clock. So when switching between OSs, they were upsetting each other. He
had found a way of making Windows leave things such that Linux is happy,
but it involved him doing something in a GUI; I was just suggesting he
automate what he was doing in the GUI by command-line - er - commands,
and putting those in a batch file that was in (or called from) his
Startup folder, so he didn't have to do it himself. Paul came up with
three Linux commands that changed how Linux operated - I wasn't sure
whether these were to be used once or whether they needed to be put into
the Linux equivalent of a batch-file-in-startup.

But is isn't just a matter of "sorting out the time on ... Windows
machines"; it's a matter of either changing the way one of them works
permanently (if that's possible), or running a batch file (or Linux
equivalent) each time the relevant OS starts. [While still letting both
OSs continue to implement DST.]
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Security is the perfect excuse to lock you out of your own computer.
- Mayayana in alt.windows7.general, 2015-12-4

On 02/04/2018 02:14, J. P. Gilliver (John) wrote:
In message ,
writes:

On Sun, 1 Apr 2018 13:01:42 +0100, "J. P. Gilliver (John)"
wrote:

In message , Roderick
Stewart writes:
[]
For the next six months or so I'll have to remember to correct the
time on my computer every time I boot it into Windows after using
Linux.

Since it looks unlikely that it will )-:, can't you put a batch file to
do that off-and-then-on-again into your startup folder?

I use [snip]

My understanding of the problem was that he _wasn't_ having a problem
sorting the time on his Windows machine(s), but that he was dual-booting
one machine in Windows and Linux, and one of those OSs implements DST by
leaving the computer's in-built clock alone and adding an hour to it as
necessary, whereas the other one was actually adjusting the in-built
clock.

Correct, but potentially there's an easy fix for the problem, as I've
already explained, it's just a question of finding the relevant setting
in any given Linux distro.

I have to reinstall fairly regularly because I do a lot of
cross-compiling, and far too many of the installation routines that I
have to get to cross-compile have been badly written and inadequately
tested, tend to ignore the relevant command-line variables, and f**k the
host system by trying to install cross-compiled code there rather than
the intended target sysroot. Therefore, I've scripted all my Ubuntu
customisations - an hour or two after re-installation completes, I
have a totally rebuilt machine with all the correct updates and
settings, including obviously the time settings. That's why I know the
console command-line settings for Ubuntu, and therefore probably most
Debian-based distros, but not how to do it within the Settings GUI, if
indeed the latter's possible.

But is isn't just a matter of "sorting out the time on ... Windows
machines"; it's a matter of either changing the way one of them works
permanently (if that's possible)

Yes, it is, as I've already explained.

On 01/04/2018 17:13, Paul wrote:

J. P. Gilliver (John) wrote:

In message , Roderick
Stewart writes:
[]
For the next six months or so I'll have to remember to correct the
time on my computer every time I boot it into Windows after using
Linux.

Since it looks unlikely that it will )-:, can't you put a batch file
to do that off-and-then-on-again into your startup folder?

I find it unbelievable that this is necessary.

As we have both explained, it isn't.

As for DST behavior, it's programmable too. After my
Win2K stopped receiving updates, you could use a command
on Win2K to manually enter the date when DST change should
happen. While a later OS like WinXP would get a TZ patch
with the details, you could effect the same changes manually
in a minute or two. The application might have been
tzedit or the like.

I don't understand why this was necessary with Win2k. My monitor died
in a pall of black smoke a month or two back, so I can't do anything
useful with either of my old W2k machines which are both desktops, and
consequently cannot check that they have changed their RTC this equinox,
but always they have done so in the past, without any manual
intervention on my part.

J. P. Gilliver (John) wrote:

In message ,
writes:
On Sun, 1 Apr 2018 13:01:42 +0100, "J. P. Gilliver (John)"
wrote:

In message , Roderick
Stewart writes:
[]
For the next six months or so I'll have to remember to correct the
time on my computer every time I boot it into Windows after using
Linux. It's not difficult - I just go to the settings page that has
the little switch for "Set time automatically" and follow the
traditional procedure of switching it off and switching it on again -
but I always have to remember to do it, so the sooner this nonsense
ends permanently, the better.

Since it looks unlikely that it will )-:, can't you put a batch file to
do that off-and-then-on-again into your startup folder? I'd be surprised
if there isn't a command line version of "go to the settings page and
... switching it off and switching it on again". (Crossposted to a
Windows 'group - may not be the right one, don't know which one you're
using - as someone there is likely to know the correct incantations.)

Rod.
John

I use a simple time sync prog called Neutron that will sort out the
time on all my Win machines.. While I haven't had any trouble with
Windows knowing what date the time changes (that was covered in a
patch back when they moved the date) Neutron also syncs the time in my
machines with a NIST server to make them all within a second or so of
each other

My understanding of the problem was that he _wasn't_ having a problem
sorting the time on his Windows machine(s), but that he was dual-booting
one machine in Windows and Linux, and one of those OSs implements DST by
leaving the computer's in-built clock alone and adding an hour to it as
necessary, whereas the other one was actually adjusting the in-built
clock. So when switching between OSs, they were upsetting each other. He
had found a way of making Windows leave things such that Linux is happy,
but it involved him doing something in a GUI; I was just suggesting he
automate what he was doing in the GUI by command-line - er - commands,
and putting those in a batch file that was in (or called from) his
Startup folder, so he didn't have to do it himself. Paul came up with
three Linux commands that changed how Linux operated - I wasn't sure
whether these were to be used once or whether they needed to be put into
the Linux equivalent of a batch-file-in-startup.

But is isn't just a matter of "sorting out the time on ... Windows
machines"; it's a matter of either changing the way one of them works
permanently (if that's possible), or running a batch file (or Linux
equivalent) each time the relevant OS starts. [While still letting both
OSs continue to implement DST.]

Windows has its own software timeclock (system time). I don't know what
his Linux does to the RTC chip.

https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
"When [Windows] first starts, it sets the system time to a value based
on the real-time clock of the computer and then regularly updates the
time."

After Windows copies the current date/time value from the RTC chip via
BIOS call, it updates its own software clock but NTP can be used (e.g.,
Internet time sync tool) to periodically correct the software clock
(because they aren't as accurate as a hardware clock). In fact, Windows
7 has its own "Windows Time" service for NTP updates to its software
clock (but takes some registry editing if you want to use different NTP
servers than those in the default install-time list). Workstations poll
whatever NTP server they've been configured to use (I forget the default
and don't care to check since I don't use it). Client hosts in a domain
use NTP to the PDC (primary domain controller). I suspect policies
pushed from the PDC onto the client define what NTP server the client
will use. The PDC is configured as to what NTP server it will use.

I find it very hard to believe that any Linux doesn't support NTP.

RTC chips have their own source of power since A/C or source power may
get disconnected. Some use a lithium battery while newer designs might
use a supercapacitor. Some may be writable, like a Counter register
that cannot be written and only reset to zero with a separate CC
register that can be written to vary intervals between events. In newer
designs, the RTC chip was integrated into the southbridge chip.

For DST, Windows is changing the value of its own software clock, not
writing to the RTC chip or southbridge chip. Why would Linux be
altering hardware parameters?

I would imagine that this thread is rapidly becoming as confusing to the
OP as the Toshiba one was - too many people posting without reading
what has already been posted ...

On 02/04/2018 10:39, VanguardLH wrote:

I find it very hard to believe that any Linux doesn't support NTP.

On 01/04/2018 16:09, Java Jive wrote:

timedatectl set-ntp true # Use internet time

On Mon, 2 Apr 2018 02:14:45 +0100, "J. P. Gilliver (John)"
wrote:

In message ,
writes:
On Sun, 1 Apr 2018 13:01:42 +0100, "J. P. Gilliver (John)"
wrote:

In message , Roderick
Stewart writes:
[]
For the next six months or so I'll have to remember to correct the
time on my computer every time I boot it into Windows after using
Linux. It's not difficult - I just go to the settings page that has
the little switch for "Set time automatically" and follow the
traditional procedure of switching it off and switching it on again -
but I always have to remember to do it, so the sooner this nonsense
ends permanently, the better.

Since it looks unlikely that it will )-:, can't you put a batch file to
do that off-and-then-on-again into your startup folder? I'd be surprised
if there isn't a command line version of "go to the settings page and
... switching it off and switching it on again". (Crossposted to a
Windows 'group - may not be the right one, don't know which one you're
using - as someone there is likely to know the correct incantations.)

Rod.
John

I use a simple time sync prog called Neutron that will sort out the
time on all my Win machines.. While I haven't had any trouble with
Windows knowing what date the time changes (that was covered in a
patch back when they moved the date) Neutron also syncs the time in my
machines with a NIST server to make them all within a second or so of
each other

My understanding of the problem was that he _wasn't_ having a problem
sorting the time on his Windows machine(s), but that he was dual-booting
one machine in Windows and Linux, and one of those OSs implements DST by
leaving the computer's in-built clock alone and adding an hour to it as
necessary, whereas the other one was actually adjusting the in-built
clock. So when switching between OSs, they were upsetting each other. He
had found a way of making Windows leave things such that Linux is happy,
but it involved him doing something in a GUI; I was just suggesting he
automate what he was doing in the GUI by command-line - er - commands,
and putting those in a batch file that was in (or called from) his
Startup folder, so he didn't have to do it himself. Paul came up with
three Linux commands that changed how Linux operated - I wasn't sure
whether these were to be used once or whether they needed to be put into
the Linux equivalent of a batch-file-in-startup.

But is isn't just a matter of "sorting out the time on ... Windows
machines"; it's a matter of either changing the way one of them works
permanently (if that's possible), or running a batch file (or Linux
equivalent) each time the relevant OS starts. [While still letting both
OSs continue to implement DST.]
OK.. My Bad.. I couldn't find the OP so I just ran with it..
So, if I understand this correctly.. L is using the Bios' clock and W
is only basing it on the Bios' clock and correcting as needed? Then
why not alter the Bios' clock to what you want L to see and use W's
ability to access Internet time servers for W time
...and use a hammer for Hammer time.
sorrynotsorry

On 02/04/2018 18:07, wrote:


OK.. My Bad.. I couldn't find the OP so I just ran with it..

Still your bad, see below ...

So, if I understand this correctly.. L is using the Bios' clock and W
is only basing it on the Bios' clock and correcting as needed?

No, you're not understanding this correctly, and therefore should not be
presuming to post on the topic, because by doing so you are making the
thread unnecessarily complicated, and distracting the OP down lines of
enquiry that won't solve his problem. The solution to his problem is as
I've already given it up thread, and at least until he has tried it and
reported back, almost every post since has been superfluous and merely a
source of unnecessary confusion.

For your and other Windows users' information, both Linux and Windows
set the RTC, but by default Linux sets it to universal time UTC, whereas
Windows bases it on local daylight savings time. When the PC is turned
off, the RTC is powered by the CMOS battery and keeps its local hardware
copy of the time up-to-date as best it can, so that when the PC is next
turned on, the RTC can be read by the OS as it boots, and will be
approximately correct. However, RTCs are usually not that accurate, so
by default nearly all modern operating systems keep sync their time with
internet time as soon as an internet connection become available.

UTC is the scientific successor to and (virtually) the same as GMT, so
it happens that here in the UK, because we are on the Greenwich
Meridian, it is also the same as UK winter time. However, in summer
time UK clocks go forward one hour, and so are no longer in sync with
GMT/UTC, hence only then to do some UK users of newly set up dual-boot
PCs notice that their Linux time settings are awry, which is what
appears to have happened to the OP. However, the fix is a relatively
simple one, to set Linux to set the RTC to local time, as I've explained
up thread.

Then
why not alter the Bios' clock to what you want L to see and use W's
ability to access Internet time servers for W time

No this won't work, because you don't understand how the RTC clock is
used by either operating system.

Java Jive wrote:

However, the fix is a relatively simple one, to set Linux to set
the RTC to local time, as I've explained up thread.

And this is the preferred method, with fewest side effects.

You can also "make" Windows bend to conform to the Linux
way, but that has side effects. Setting your Linux to
use Local Time when it's updating the RTC, is likely to be a better choice.

*******

A tiny tidbit people might not be getting here, is how OS time works.

System boots

OS copies RTC_time (i.e. BIOS time) to software clock.
OS increments software clock based on hardware interrupts (clock_tick or similar).
During the day, the software clock "drifts" with respect to the RTC.

System needs to shut down.
OS can copy the software clock, back into the RTC.
And a given OS assumes its choice of hours-keeping, is the only
choice, so if it uses LocalTime, every OS is using LocalTime.

(RTC runs on the CMOS clock battery if all power is lost.
RTC runs on +5VSB if you leave PC power ON at the back.
RTC "keeps the time", when the OS is not available to do it.)

While NTP is an additional variable, the polling rate of NTP
is on purpose, way too low, to be used as a "crutch" to fix this LocalTime
issue. For example, my current OS only checks in with NTP
once a week, so if I had a LocalTime/UTC issue, it would
take a week without intervention, to get some sort of
correction.

Using the setting in Linux, and selecting LocalTime, will
remove at least one variable from all of this.

https://help.ubuntu.com/community/UbuntuTime

"Make Linux use 'Local' time

Pre-Ubuntu 15.04 systems...
Ubuntu 15.04 systems and above...
"

*******

You can also have issues on multiple OSes, if the DST rules
are not consistent between them. But that's a different discussion.
First set your Linux to use LocalTime with the RTC, then
go back and see if everything is OK or not :-)

Paul

VanguardLH wrote:

Windows has its own software timeclock (system time). I don't know what
his Linux does to the RTC chip.

https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
"When [Windows] first starts, it sets the system time to a value based
on the real-time clock of the computer and then regularly updates the
time."

After Windows copies the current date/time value from the RTC chip via
BIOS call, it updates its own software clock but NTP can be used (e.g.,
Internet time sync tool) to periodically correct the software clock
(because they aren't as accurate as a hardware clock). In fact, Windows
7 has its own "Windows Time" service for NTP updates to its software
clock (but takes some registry editing if you want to use different NTP
servers than those in the default install-time list). Workstations poll
whatever NTP server they've been configured to use (I forget the default
and don't care to check since I don't use it). Client hosts in a domain
use NTP to the PDC (primary domain controller). I suspect policies
pushed from the PDC onto the client define what NTP server the client
will use. The PDC is configured as to what NTP server it will use.

I find it very hard to believe that any Linux doesn't support NTP.

RTC chips have their own source of power since A/C or source power may
get disconnected. Some use a lithium battery while newer designs might
use a supercapacitor. Some may be writable, like a Counter register
that cannot be written and only reset to zero with a separate CC
register that can be written to vary intervals between events. In newer
designs, the RTC chip was integrated into the southbridge chip.

For DST, Windows is changing the value of its own software clock, not
writing to the RTC chip or southbridge chip. Why would Linux be
altering hardware parameters?

https://developer.toradex.com/knowle...clock-in-linux
Two clocks are important in Linux: a ¡hardware clock¢, also known as
RTC, CMOS or BIOS clock. This is the battery backed clock that keeps
time even when the system is shut down. The second clock is called the
¡system clock¢ or 'kernel clock' and is maintained by the operating
system. At boot time, the hardware clock is read and used to set the
system clock. From that point onward the system clock is used to track
time.

So this embedded Linux is doing the same routine as Windows when the OS
loads: *copy* the hardware RTC value into a software clock and it is the
software clock that the OS uses thereafter. Probably the same for all
variants of Linux.

http://tldp.org/HOWTO/Clock-2.html
A Linux system actually has two clocks: One is the battery powered "Real
Time Clock" (also known as the "RTC", "CMOS clock", or "Hardware clock")
which keeps track of time when the system is turned off but is not used
when the system is running. The other is the "system clock" (sometimes
called the "kernel clock" or "software clock") which is a software
counter based on the timer interrupt. It does not exist when the system
is not running, so it has to be initialized from the RTC (or some other
time source) at boot time. References to "the clock" in the ntpd
documentation refer to the system clock, not the RTC.

Yep, Linux works the same as Windows. That something altered in the
system/software clock in Linux affects the system/software clock in
Windows has nothing to do with the value in the RTC hardware circuit.
Those are two separate software clocks in separate operating systems
(which apparently are not loaded at the same time due to multi-booting
on the same hardware platform).

At this point, the only way that I can figure the Linux system clock
could affect the Windows system clock is both are up and running at the
same time and Windows is using the Linux host as its NTP server.
Another possibility is a dead battery (that keeps the RTC powered after
a power loss). Perhaps the multi-booted host is getting powered off by
disconnecting whatever is its source of A/C power to its PSU. Even with
the computer turned off, having A/C power has the ATX PSU still supply
5V standby to power-on logic on the motherboard which is reduced to 3V
for the RTC battery. Only by yanking the power cord or losing the input
A/C power source to the PSU would the 3V be absent and the RTC battery
take over to keep time during total power loss.

https://en.wikipedia.org/wiki/System_time
System time is measured by a system clock, which is typically
implemented as a simple count of the number of ticks that have
transpired since some arbitrary starting date, called the epoch. For
example, Unix and POSIX-compliant systems encode system time ("Unix
time") as the number of seconds elapsed since the start of the Unix
epoch at 1 January 1970 00:00:00 UT, with exceptions for leap seconds.
Systems that implement the 32-bit and 64-bit versions of the Windows
API, such as Windows 9x and Windows NT, provide the system time as both
SYSTEMTIME, represented as a
year/month/day/hour/minute/second/milliseconds value, and FILETIME,
represented as a count of the number of 100-nanosecond ticks since 1
January 1601 00:00:00 UT as reckoned in the proleptic Gregorian
calendar.

If the battery were dead, the RTC logic would also be dead and lose
track of time although I through it would reset back to the epoch date
or whatever is Year One in the OS that reads the RTC's zero value.
System clocks base their date on a bias or starting date from the value
of the RTC). The RTC reset to zero with a dead battery means losing the
input power source to the PSU. Instead of powering off the computer,
the user would have to be yanking the power cord, flipping a switch on a
power/surge strip, turning off a wall switch that controls a wall
outlet, or other means of totally removing input power. I can't see
losing power between switching between Linux to Windows on the same host
would change the system time in Windows by just one hour.

That Windows gets off by only 1 hour when it reads the RTC when it loads
after having used Linux on that host is mostly like a screw up by the
user in the timezone or DST configuration in Windows. The user needs to
select the correct timezone or stop Windows from automatically altering
its system clock on the DST change days.

"Paul" wrote in message
news
A tiny tidbit people might not be getting here, is how OS time works.

System boots

OS copies RTC_time (i.e. BIOS time) to software clock.
OS increments software clock based on hardware interrupts (clock_tick
or similar).
During the day, the software clock "drifts" with respect to the RTC.

System needs to shut down.
OS can copy the software clock, back into the RTC.
And a given OS assumes its choice of hours-keeping, is the only
choice, so if it uses LocalTime, every OS is using LocalTime.

(RTC runs on the CMOS clock battery if all power is lost.
RTC runs on +5VSB if you leave PC power ON at the back.
RTC "keeps the time", when the OS is not available to do it.)

While NTP is an additional variable, the polling rate of NTP
is on purpose, way too low, to be used as a "crutch" to fix this LocalTime
issue. For example, my current OS only checks in with NTP
once a week, so if I had a LocalTime/UTC issue, it would
take a week without intervention, to get some sort of
correction.

Following an earlier discussion on this thread a week or so, I've now
tweaked my registry so the PC polls its NTP server every 24 hours rather
than every week to bring it back into sync. Before I did this, I found that
my desktop PC which remains on 24/7 as a server, video recorder and
weather-station data-acquisition, was getting out of sync with my laptop
which gets put to sleep and woken up fairly frequently and so is relying on
accuracy of RTC more than the desktop which relies entirely on OS clock. The
difference was sometimes as much as a couple of minutes, which I cured
either by forcing an unscheduled NTP sync with the internet server, or else
by "net time \\server-PC /set /y" from a elevated DOS prompt, as and when I
noticed it.

Now it's rare for me to see the two PCs displaying a different time. Just
now, I noticed the difference was about 10 seconds, and both PCs are
probably due to resync fairly soon. The time.is website has just shown that
the laptop is 11 seconds slow and the desktop is bang on. A drift of 10
seconds or so per day (as long as it's not cumulative!) is something I can
live with.