Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot

On Feb 24, 2023, at 13:05, bob prohaska <fbsd@www.zefox.net> wrote:

> After installing 
> FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230223-fe5c211ba873-261074.img
> on a Pi3 and setting up the hard disk to use separate swap and /usr partitions
> an oddity came to light regarding dates.
> 
> The image file was written to disk the night of the 23rd, from a Pi3 with
> a correctly-set time and date. It was left idle overnight, configured the
> morning of the 24th and booted without issue. It then cloned -current into
> /usr/src, at which point the time was noticed to be wrong, apparently fast.
> 
> It turned out ntpdate wasn't running, so it was started and then tzsetup
> run. After a reboot the time reported correctly. 
> 
> However, make buildworld in /usr/src triggers an exhortation to "check
> your time" and refuses run further. 
> 
> running date on the system reports
> Fri Feb 24 12:49:41 PST 2023
> but ls -l /usr/src reports time around 
> Feb 24 19:10
> an obvious inconsistency.
> 
> Presumably just waiting until the system clock catches
> up with the /usr/src timestamps will fix the error. Is
> there a better method?
> 
> Still, the date and time handling don't seem quite right. 
> In at least one earlier instance it appeared that tzsetup 
> altered the reported timeszone without shifting the time
> stamp by the UTC/PDT offset. I always thought timestamps
> were internally in UTC+timezone, displayed with the right
> offset. It looks to a casual observer like something else
> is going on. 
> 
> An earlier fiasco (on this same Pi3) included wildly wrong
> timestamps in a filesystem. The Pi3 has no hardware clock,
> how does it set time when booted without a reference?

There are 2 files involved:

     /etc/localtime        Current zoneinfo file, see tzsetup(8) and zic(8).

     /etc/wall_cmos_clock  Empty file.  Its presence indicates that the
                           machine's CMOS clock is set to local time, while
                           its absence indicates a UTC CMOS clock.

An oddity here is that there is no existing
CMOS clock but the /etc/wall_cmos_clock
status still has consequences, as I remember.

Various related man pages are:

adjkerntz(8)
tzseteup(8)
zic(8)

From an RPi4B:

# ls -Tld /etc/wall_cmos_clock
ls: /etc/wall_cmos_clock: No such file or directory
# sysctl machdep.wall_cmos_clock
machdep.wall_cmos_clock: 0

(So: As if a CMOS clock was using UTC time.)


# strings /etc/localtime | tail -1
PST8PDT,M3.2.0,M11.1.0

# sysctl machdep.adjkerntz
machdep.adjkerntz: 0

# date
Fri Feb 24 13:42:52 PST 2023

(Matching the local time.)

So, as configured, /etc/localtime is used to
specify covert kernel UTC to local time as
needed: no addition non-zero offsets.

As I remember, things can be odd with file
systems from Windows variants and the time
stamps interpretation. Keeping such matching
vs. not can get into the choice of if
/etc/wall_cmos_clock is to exist or not.

It can be a seprate issue if time tracking
is off rate or some such.

===
Mark Millard
marklmi at yahoo.com