Date: Sun, 5 Aug 2018 17:08:57 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Conrad Meyer <cem@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r337334 - head/lib/libc/sys Message-ID: <20180805161913.C1770@besplex.bde.org> In-Reply-To: <201808042208.w74M8OmD057603@repo.freebsd.org> References: <201808042208.w74M8OmD057603@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 4 Aug 2018, Conrad Meyer wrote: > Log: > settimeofday(2): Remove stale note about timezone > > Contrary to the removed comment, the kernel does appear to use the timezone > argument of settimeofday. The comment dates to the BSD4.4 import; I assume it > is just stale. The kernel not only appears to use the timezone set by settimeofday(), but does use it. Applications may use it too, and adjkerntz(8) does use it. The kernel and adjkerntz also use the machdep.adjkerntz and machdep.wall_cmos_clock sysctls (these are MI but have old names for compatibility), and the final utc_offset() is: (tz_minuteswest * 60 + (wall_cmos_clock ? adjkerntz : 0)) adjkerntz(8) does very little when wall_cmos_clock == 0. Otherwise, it manages tz_minuteswest, but I think this is only to compensate for other applications setting it. It gets the correct offset from userland and normally just puts that in adjkerntz, leaving tz_minuteswest as 0, but if tz_minuteswest != 0 then I think it preserves this mistake but compensates for it but adjusting adjkerntz so that the final offset comes out right. The broken comment applied to both gettimeofday() and settimeofday(), and is wrongest for gettimeofday(). The kernel really does use tz_minuteswest, and gettimeofday() is the only way to determine its setting. adjkerntz makes critical use of reading it even if it doesn't change it, to compensate for the foot shooting of other applications setting it. Of course, adjkerntz can't do much if other applications set it after adjkerntz(8) runs. adjkerntz normally runs at boot time before other applications have had much chance to clobber tz_minuteswest. Then it is possible for another application to clobber it. adjkerntz might be confused when it runs about 6 months later to adjust the dst, but the time becomong wrong immediately when the other application clobbers tz_minuteswest is a larger problem. The comment was almost correct in 4.4BSD-Lite2. get/settimeofday() supported the timezone parameter, but the kernel didn't use tz_minuteswest except in the i386 inittodr() which was only called at boot time before settimeofday() can run, and in some hp code where the use seems to be read-only. > Modified: head/lib/libc/sys/gettimeofday.2 > ============================================================================== > --- head/lib/libc/sys/gettimeofday.2 Sat Aug 4 21:57:17 2018 (r337333) > +++ head/lib/libc/sys/gettimeofday.2 Sat Aug 4 22:08:24 2018 (r337334) > @@ -28,7 +28,7 @@ > .\" @(#)gettimeofday.2 8.2 (Berkeley) 5/26/95 > .\" $FreeBSD$ > .\" > -.Dd December 27, 2015 > +.Dd August 4, 2018 > .Dt GETTIMEOFDAY 2 > .Os > .Sh NAME > @@ -44,11 +44,6 @@ > .Ft int > .Fn settimeofday "const struct timeval *tp" "const struct timezone *tzp" > .Sh DESCRIPTION > -.Bf -symbolic > -Note: timezone is no longer used; this information is kept outside > -the kernel. > -.Ef > -.Pp > The system's notion of the current Greenwich time and the current time > zone is obtained with the > .Fn gettimeofday The note should have been placed after this section to more obviously cancel what this section says about time zones. This section also doesn't say anything about the wall_cmos_clock and adjkerntz sysctls or there interaction with tz_minuteswest which is what actually determines the system's notion of the current time zone. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180805161913.C1770>