Post by VanguardLHWindows 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/library/windows/desktop/ms724961(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/knowledge-base/how-to-use-the-real-time-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.
