Deprecating tzsetwall

In reviewing the tzdb web pages for bad links and suchlike, I noticed that they're still talking about UNIX SVR2 (superseded since 1988) and tzsetwall. So I looked into tzcode's implementation of tzsetwall, and noticed that it does nothing useful because functions like localtime now call tzset (as POSIX has require for many years), thus undoing tzsetwall's effect. Since nobody evidently cares whether tzsetwall works, we should remove it. Not right away of course, but we can document it as deprecated now without changing the implementation, and remove it in a future tzcode release. So I installed the attached patch to do that. Comments welcome as usual.

sgtm. we don't expose tzsetwall in Android. On Tue, Apr 21, 2020 at 5:30 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
In reviewing the tzdb web pages for bad links and suchlike, I noticed that they're still talking about UNIX SVR2 (superseded since 1988) and tzsetwall. So I looked into tzcode's implementation of tzsetwall, and noticed that it does nothing useful because functions like localtime now call tzset (as POSIX has require for many years), thus undoing tzsetwall's effect.
Since nobody evidently cares whether tzsetwall works, we should remove it. Not right away of course, but we can document it as deprecated now without changing the implementation, and remove it in a future tzcode release. So I installed the attached patch to do that. Comments welcome as usual.

On Apr 21, 2020, at 5:30 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
In reviewing the tzdb web pages for bad links and suchlike, I noticed that they're still talking about UNIX SVR2 (superseded since 1988) and tzsetwall. So I looked into tzcode's implementation of tzsetwall, and noticed that it does nothing useful because functions like localtime now call tzset (as POSIX has require for many years), thus undoing tzsetwall's effect.
Since nobody evidently cares whether tzsetwall works, we should remove it.
In practice, it probably won't break anything, but at least one OS *does* document it: $ man tzsetwall TZSET(3) BSD Library Functions Manual TZSET(3) NAME tzset, tzsetwall -- initialize time conversion information LIBRARY Standard C Library (libc, -lc) SYNOPSIS #include <time.h> void tzset(void); void tzsetwall(void); ... The tzsetwall() function sets things up so that localtime returns the best available approximation of local wall clock time. ... $ sw_vers ProductName: Mac OS X ProductVersion: 10.15.4 BuildVersion: 19E287 and that OS *does* attempt to provide at least some level of release-to-release binary compatibility (the main forms of binary incompatibility are "we no longer support that instruction set", e.g. PowerPC and 32-bit x86). But they may be able to mark it as deprecated (provoking compiler warnings) and kill it eventually.

On 4/21/20 7:19 PM, Guy Harris wrote:
In practice, it probably won't break anything, but at least one OS *does* document it:
Yes, I saw that. I just now looked at the FreeBSD tzsetwall source code here: https://github.com/freebsd/freebsd/blob/master/contrib/tzcode/stdtime/localt... and as near as I can tell FreeBSD's tzsetwall (which is derived from old tzcode) is also busted because it is a no-op. That is, FreeBSD's localtime calls the equivalent of tzset first thing (as POSIX requires), and this tzset undoes the effect of any previous tzsetwall.

On 2020-04-21 20:10:52 (-0700), Paul Eggert wrote:
On 4/21/20 7:19 PM, Guy Harris wrote:
In practice, it probably won't break anything, but at least one OS *does* document it:
Yes, I saw that. I just now looked at the FreeBSD tzsetwall source code here:
https://github.com/freebsd/freebsd/blob/master/contrib/tzcode/stdtime/localt...
and as near as I can tell FreeBSD's tzsetwall (which is derived from old tzcode) is also busted because it is a no-op. That is, FreeBSD's localtime calls the equivalent of tzset first thing (as POSIX requires), and this tzset undoes the effect of any previous tzsetwall.
I have a long-standing todo item to update FreeBSD to newer tzcode. I won't shed a tear over tzsetwall. :) Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
participants (4)
-
enh
-
Guy Harris
-
Paul Eggert
-
Philip Paeps