/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? Charles
<<On Tue, 23 Jan 2001 21:13:07 -0800 (PST), crandall@matchlogic.com 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. -GAWollman
State Changed From-To: open->suspended 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.
Responsible Changed From-To: freebsd-bugs->freebsd-standards -standards issue.
It's marked non-conforming in time.h (see http://svn.freebsd.org/viewvc/base/head/include/time.h?view=diff&r1=144528&r2=144529 for the commit -- it was 1 year after the last activity was made to this PR): #if __BSD_VISIBLE char *timezone(int, int); /* XXX XSI conflict */ void tzsetwall(void); 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). Thanks, -Garrett
batch change of PRs untouched in 2018 marked "in progress" back to open.
There are ports in the tree which would benefit from supporting timezone in time.h. See https://svnweb.freebsd.org/ports?view=revision&revision=549926
FWIW, other BSDs fixed the conflict long ago: https://github.com/dragonflybsd/dragonflybsd/commit/7d013f9724 https://github.com/netbsd/src/commit/a495a577a009 https://github.com/openbsd/src/commit/c9da469ac913 https://opensource.apple.com/source/Libc/Libc-391/include/time.h.auto.html
(In reply to Jan Beich from comment #7) I suppose they wanted to apply for UNIX branding. That's the only reason to support these fossilized System V mistakes.
We can fix this with versioned symbols. I have a branch that fixes this and will get it reviewed.