different times for last boot between last and uptime -s

[Ralf Mardorf]

On Wed, 2022-12-07 at 15:57 -0800, Tom Mitchell wrote:
> It is valuable to look at the newer interface..
> 
> # timedatectl -a
>                Local time: Wed 2022-12-07 15:52:37 PST
>            Universal time: Wed 2022-12-07 23:52:37 UTC
>                  RTC time: Wed 2022-12-07 23:52:37
>                 Time zone: America/Los_Angeles (PST, -0800)
> System clock synchronized: yes
>               NTP service: n/a
>           RTC in local TZ: no

Hi,

indeed, what you posted provides relatively good information. However,
the OP is annoyed by the output of the "last" command.

The information of "timedatectl -a" is a little bit misleading when
using RTC in local timezone.

   [rocketmouse at archlinux ~]$ timedatectl -a
                  Local time: Thu 2022-12-08 04:57:47 CET
              Universal time: Thu 2022-12-08 03:57:47 UTC
                    RTC time: Thu 2022-12-08 04:57:47
                   Time zone: Europe/Berlin (CET, +0100)
   System clock synchronized: no
                 NTP service: inactive
             RTC in local TZ: yes
   
   Warning: The system is configured to read the RTC time in the local time zone.
            This mode cannot be fully supported. It will create various problems
            with time zone changes and daylight saving time adjustments. The RTC
            time is never updated, it relies on external facilities to maintain it.
            If at all possible, use RTC in UTC by calling
            'timedatectl set-local-rtc 0'.
   [rocketmouse at archlinux ~]$ grep pool /usr/local/bin/tool
       ntpdate 0.de.pool.ntp.org && hwclock --set --date "$(date "+%a %b %d %Y %r")";;

Updating RTC is no issue, hence the warning is moot. However, depending
on the computer usage and/or maintenance directory, file etc. timestamps
within the operating system that might go back and forth in time could
be a serious issue. If the clock is set back by e.g. one hour due to
DST/standard time or traveling through timezones a newer file can get an
older timestamp than an older file. If the directory, file etc.
timestamps are a concern related to sync, recovery etc. then RTC should
be in UTC. If this isn't a concern, but for some reason it's wanted that
the hardware clock provides local time, e.g. to get the correct local
time when saving BIOS settings, there's no issue with using local time.

For those using Windows on bare metal, the claim that Windows requires
to set the hardware clock to local time is wrong and always was wrong.
AFAIK Windows never suffered from this requirement.

To rely on UNIX timestamps can be a serious issue. If possible, it
should be avoided. Using UTC doesn't solve the
https://en.wikipedia.org/wiki/Year_2038_problem .
It's much likely no issue when following Ubuntu releases on your desktop
PC, but for e.g. a space probe beyond the Kuiper Belt Ubuntu release
updates are quite impracticable and even for one or the other domain on
this planet, far away from interstellar space, there's no valid rule
that one or the other approach is good or bad for all users.

Data set in stone are certainly the better long-term data archives.

Regards,
Ralf