Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 25 Feb 2023 09:02:38 -0800
From:      bob prohaska <fbsd@www.zefox.net>
To:        Mike Karels <mike@karels.net>
Cc:        freebsd-arm@freebsd.org, freebsd-current@freebsd.org
Subject:   Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot
Message-ID:  <20230225170238.GA11193@www.zefox.net>
In-Reply-To: <0BA0C9F7-5F85-4EBF-86BB-428730746592@karels.net>
References:  <20230224210502.GA8127@www.zefox.net> <1216867532.11893.1677280869319@localhost> <20230225161625.GB8127@www.zefox.net> <0BA0C9F7-5F85-4EBF-86BB-428730746592@karels.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 25, 2023 at 10:33:23AM -0600, Mike Karels wrote:
> On 25 Feb 2023, at 10:16, bob prohaska wrote:
> 
> > On Sat, Feb 25, 2023 at 12:21:09AM +0100, Ronald Klop wrote:
> >>
> >> UFS stores the current timestamp in the superblock of the FS on clean
> >> shutdown/unmount. On boot it reads the time from the timestamp in the
> >> superblock of the root FS. Of coarse this timestamp is behind for the
> >> duration that the machine was off or rebooting so you need to adjust that
> >> using ntp. For ZFS root you can use the fakertc port to do something
> >> similar.
> >>
> >>
> > Mark Millard points out:
> >      /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.
> >
> > Since there is no /etc/wall_cmos_clock on the newly-installed filesystem
> > it appears the superblock timestamp is then interpreted as UTC when a Pi
> > boots, using whatever happens to be set in /etc/localtime. My confusion
> > is reduced somewhat. On first boot, what is the state of /etc/localtime?
> >
> > I've neglected to run tzsetup immediately on many previous installations
> > and not noticed any complaints about mis-set clocks in buildworld. Is this
> > new behavior?
> 
> /etc/localtime is used in formatting dates (e.g. for ls), but is not
> involved in storage of timestamps.  Timestamps on files, system time, etc,
> are all in UTC.  So the system should act normally if there is no
> /etc/localtime, and after one is added.

Does formatting include calculating offsets from UTC for display?

On at least a couple of installs I've observed date reporting UTC time. 
After running tzsetup, set to PST, date then reported the same numerical
time with a PST time zone. This happened very early in an installation
lifecycle and seemed to just "go away" after a few reboots, though I
never paid close attention since it caused no complaints.

Thanks for replying!

bob prohaska
 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20230225170238.GA11193>