Bug 24590 - timezone function not compatible witn Single Unix Spec v2
Summary: timezone function not compatible witn Single Unix Spec v2
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: standards (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-standards (Nobody)
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2001-01-24 05:20 UTC by crandall
Modified: 2018-05-23 10:27 UTC (History)
0 users

See Also:


Attachments
note-timezone-xsi-incompatibility.patch (444 bytes, patch)
2011-01-29 20:25 UTC, Garrett Cooper
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description crandall 2001-01-24 05:20:01 UTC
/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
Comment 1 Garrett A. Wollman 2001-01-24 17:52:34 UTC
<<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
Comment 2 Jens Schweikhardt freebsd_committer 2001-06-14 11:05:14 UTC
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.
Comment 3 Johan Karlsson freebsd_committer 2002-08-19 19:52:14 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-standards

-standards issue.
Comment 4 Garrett Cooper 2011-01-29 20:25:18 UTC
    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
Comment 5 Eitan Adler freebsd_committer freebsd_triage 2018-05-23 10:27:13 UTC
batch change of PRs untouched in 2018 marked "in progress" back to open.