Date: Mon, 3 May 2021 11:24:02 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Timezone problems on -current Message-ID: <3E0512C0-7667-44C4-B64B-501783C5B210@yahoo.com> In-Reply-To: <20210503153442.GB37236@www.zefox.net> References: <20210503153442.GB37236@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-May-3, at 08:34, bob prohaska <fbsd at www.zefox.net> wrote: > It seems that the timezone gets screwed up each time the OS is > upgraded on a Pi4 via sources on -current. ntpdate is working, but the > machine reports a local time of > bob@nemesis:~ % date > Mon May 3 15:27:04 PDT 2021 > while a Pi2 reports > fbsd@www:~ % date > Mon May 3 08:28:35 PDT 2021 > > The timezone is PDT in both cases, but the time shown looks like > UTC for the Pi4 but PDT for the Pi2. Note: I assume that neither RPi* has a RTC, not that it makes much of a difference here. I expect that one RPi* has a file: # ls -Tld /etc/wall_cmos_clock -r--r--r-- 1 root wheel 0 Aug 8 01:49:01 2017 /etc/wall_cmos_clock and the other does not. QUOTE ( from https://www.freebsd.org/cgi/man.cgi?adjkerntz(8) ) . . . . . . If the file /etc/wall_cmos_clock exists, it means that the CMOS clock keeps local time (MS-DOS and MS-Windows compatible mode). If that file does not exist, it means that the CMOS clock keeps UTC time. . . . /etc/wall_cmos_clock Empty file. Its presence indicates that the ma- chine's CMOS clock is set to local time, while its absence indicates a UTC CMOS clock. END QUOTE However, it has an effect on time handling even when no RTC (no CMOS clock) is present. If you want times to look right on ms-dos and Windows for the msdos file system involved, you then want to boot and synchronize time with /etc/wall_cmos_clock present. Otherwise you likely do not want /etc/wall_cmos_clock present for such activities. If you want times to closely agree, all RPi*'s should have the same /etc/wall_cmos_clock status, which ever way you go. There can be an issue of time going backwards, depending on the delete vs. add action for /etc/wall_cmos_clock . > I've noticed this before and cured it for a while by running tzsetup. > The problem seems to return each time the OS is upgraded, though I > have not kept careful track of what's going on. Anybody else noticed > this? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E0512C0-7667-44C4-B64B-501783C5B210>