Date: Sat, 25 Feb 2023 11:26:07 -0600 From: Mike Karels <mike@karels.net> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot Message-ID: <79CD9E36-93FF-44C2-99C4-B3CC5AEBB466@karels.net> In-Reply-To: <20230225170238.GA11193@www.zefox.net> References: <20230224210502.GA8127@www.zefox.net> <1216867532.11893.1677280869319@localhost> <20230225161625.GB8127@www.zefox.net> <0BA0C9F7-5F85-4EBF-86BB-428730746592@karels.net> <20230225170238.GA11193@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25 Feb 2023, at 11:02, bob prohaska wrote: > 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? Yes, I was referring to the process of converting from a binary timestamp in seconds since the epoch to a string with day/month/year/hour/minute etc in the local timezone. > 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. I have never seen such a thing. On the contrary, I have noticed files with timestamps that seemed to be in the future, then realized that they were in UTC; I set the timezone, and then they appeared to have recent times. I’d expect similar behavior from date unless the -u flag was used or the timezone was different in the environment. Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?79CD9E36-93FF-44C2-99C4-B3CC5AEBB466>