different times for last boot between last and uptime -s

[Ralf Mardorf]

On Tue, 2022-12-06 at 07:11 +0000, Colin Law wrote:
> Do you dual boot with windows? I believe that Windows sets the RTC to
> local time, Linux sets it to UTC.

This...

On Mon, 2022-12-05 at 23:38 +0100, Lentes, Bernd wrote:
> root at crispor-server:~# timedatectl show --all
> Timezone=Europe/Berlin
> LocalRTC=no
> [snip]
> TimeUSec=Mon 2022-12-05 23:10:39 CET
> RTCTimeUSec=Mon 2022-12-05 23:10:40 CET

...shows that the OP's battery buffered hardware clock (RTC) is set to
UTC when running timedatectl.
RTCTimeUSec=Mon 2022-12-05 23:10:40 CET means that
at this moment the RTC is  22:10:40 UTC.

If another operating system would set the RTC to CET, then at startup,
before the system clock is initialized, there wouldn't be a hour
missing. It's behind for an hour, since the RTC is set correctly to the
wanted UTC and no other operating system does set it to CET. If another
operating system would set the RTC to CET, then the clock wouldn't be a
hour behind, it would be +- 0.

On Tue, 2022-12-06 at 00:05 -0500, gene heskett wrote:
> Actually Ralf, the OP could have an erronious Locale entry, or a very 
> stale tzdata file. I much prefer the HWclock is on UTC and the tzdata 
> file is updated when apt wants to update it, then if Locale is correct, 
> the date query should return the local time, with the HWClock on UIC. 
> And everything Just Works.

Gene, I'm in the same time zone as the OP. Actually everything seems to
work correctly. My RTC is set to use CET instead of UTC and I get

[rocketmouse at archlinux ~]$ last -3
rocketmo pts/0        :0               Thu Dec  1 09:53 - 11:22  (01:28)
rocketmo tty7         :0               Fri Nov 25 15:03    gone - no
logout
reboot   system boot  4.19.265-rt117-0 Fri Nov 25 15:02   still running

wtmp begins Thu Apr  4 12:47:25 2019
[rocketmouse at archlinux ~]$ timedatectl show --all
Timezone=Europe/Berlin
LocalRTC=yes
CanNTP=yes
NTP=no
NTPSynchronized=no
TimeUSec=Tue 2022-12-06 10:42:59 CET
RTCTimeUSec=Tue 2022-12-06 11:42:57 CET

"last" does show the correct time for the system boot in CET on my
machine (I compared it with handwritten notes), while for the OP it is 1
hour behind since the OP's RTC is set to UTC. This is expected. Btw. it
might not be related to the system clock initialized or not initialized,
that the OP's "last" does report to be a hour behind. Probably "last"
does report the RTC and not the system clock time even after
initialisation, taking a look at  man last ,  man wtmp ,  man rtc  etc.
might or might not reveal the reason.

However, as you can see on my machine TimeUSec shows 10:42 CET, but
RTCTimeUSec does show 11:42 CET. Actually the RTC on my machine is not
at 11:42 it is on 10:42. The command assumes UTC for the RTC, hence an
hour gets added.

So everything is ok on the OP's and on my machine (assuming timedatectl
and last on Ubuntu and Arch don't differ). It's just a misinterpretation
of the reported times, that does cause the confusion.

We know similar issues for other commands, when it's not clear if sizes
are e.g. reported in GB or GiB.

[rocketmouse at archlinux ~]$ man ls | grep "The  SIZE"
       The  SIZE  argument  is  an integer and optional unit (example:
10K is 10*1024).  Units are K,M,G,T,P,E,Z,Y (powers of 1024) or
KB,MB,... (powers of 1000).  Binary prefixes can be

IOW if ls shows GB, it's for real GiB and not for real GB.

If Windows would cause such confusion, we wouldn't be reserved with
criticism. Actually Linux isn't that perfect, too.

Btw. my machine is a Linux multi-boot only, no Windows install on bare
metal is involved.

Regards,
Ralf