From nobody Sat Feb 25 17:26:07 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PPDFF5rqNz3tfyX; Sat, 25 Feb 2023 17:26:09 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PPDFF5QKLz3r3N; Sat, 25 Feb 2023 17:26:09 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.16.1/8.16.1) with ESMTP id 31PHQ84E064918; Sat, 25 Feb 2023 11:26:08 -0600 (CST) (envelope-from mike@karels.net) Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id u8IeILBE+mOU/QAAs/W3XQ (envelope-from ); Sat, 25 Feb 2023 11:26:08 -0600 From: Mike Karels To: bob prohaska Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot Date: Sat, 25 Feb 2023 11:26:07 -0600 X-Mailer: MailMate (1.14r5937) 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> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4PPDFF5QKLz3r3N X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N 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