/usr/include/time.h includes a prototype for the timezone() function.
The timezone(3) manual page indicates that this function is for
compatibility purposes only and notes that the timezone() function
first appeared in AT&T Unix V7.
Version 2 of the Single Unix Specification (www.opengroup.org)
states that time.h defines a global variable named timezone
which indicates the difference in seconds between the local
timezone and UTC. It also notes that this is, "Derived from Issue
1 of the SVID."
I realize that I can work around this in an application a number
of ways. For example, use FreeBSD's tm_gmtoff member of struct tm.
However, is it a long-term goal for FreeBSD to conform to the
Single Unix Specification?
<<On Tue, 23 Jan 2001 21:13:07 -0800 (PST), firstname.lastname@example.org said:
> I realize that I can work around this in an application a number
> of ways. For example, use FreeBSD's tm_gmtoff member of struct tm.
> However, is it a long-term goal for FreeBSD to conform to the
> Single Unix Specification?
It is a long-term goal for FreeBSD to conform to POSIX and include as
much Single UNIX Spec (aka XSI) functionality as seems useful and
prudent. We are not likely to change the API in the way that you
suggest, precisely because superior alternatives exist, and changing
to the XSI definition would break backward compatibility.
According to Garrett Wollmann:
I think suspended is probably the right state. There has been some
movement on fixing the time APIs recently, although it will not make
it into this review cycle. It's worth keeping the PR around for the
next time someone notices this difference.
It's marked non-conforming in time.h (see
for the commit -- it was 1 year after the last activity was made to
char *timezone(int, int); /* XXX XSI conflict */
time_t timelocal(struct tm * const);
time_t timegm(struct tm * const);
#endif /* __BSD_VISIBLE */
This attached patch to the timezone(3) manpage makes the XSI
conformance `issue' more apparent (it might not be a good final
solution, but at least it documents the problem outside of GNATs).
As far as the option is concerned, yes it's required by BASE, and
we may or may not want to grab some of the bits from NetBSD to
properly rename this function for the purposes of resolving this
conformance issue, but that's a larger effort than documenting the
issue is (for now).
batch change of PRs untouched in 2018 marked "in progress" back to open.