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

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