- tz - lists.iana.org

Re: what should be in POSIX vs X3J11
by seismo!sun!guy May 6, 1987

May 6, 1987

I believe the way out of this 'who should do it?' problem is to only place those functions that are uniquely OS-related into POSIX. They are 'time()' and 'stime()'. Our task would then be to decide what arguments they take and what errors are defined. X3J11 should deal with the C library functions -- those in section 3 of some Unix manuals. This isn't an adequate definition of a "C library function". "getpwent" is in section 3 of some UNIX manuals, but it is definitely not a C function. Additional functions can be created within the domain of X3J11 but these should not be required for POSIX. As Robert Elz and others pointed out, POSIX should be the base on which different language environments may run. Imagine how a program would be written using Pascal's date/time manipulation functions. There probably won't be an asctime() call. I wouldn't bet on that. There may have to be some equivalent procedure; Pascal doesn't *have* any date/time manipulation functions. Frankly, I don't think C should have them, either. The standard UNIX library is called the "C library", but this is a misnomer. It contains some functions that may be considered language support for C, some functions that can be considered part of the operating system, and some functions that are really just useful utilities. The Standard I/O library routines are probably best considered to be language support for C (one might also consider them to be part of the operating system, except that the same interfaces have been implemented under other operating systems, and the intent seems to be that all C implementations should have those routines). "open" is clearly part of the operating system, as is "getpwent". "lsearch" is clearly just a utility; the code for "lsearch" could be transplanted to another OS with no trouble (except for possibly writing a "memcpy" routine), and could also be rewritten in any other language that supports the requisite data types. Neither POSIX nor X3J11 includes "lsearch". Although this means that portable code can't use it (or other potentially more interesting utility routines), this is arguably the correct thing to do. However, X3J11 includes some routines that could be considered utility routines or operating system interfaces. The date/time conversion routines fall into these categories: If the format of a "time_t" is considered to be a characteristic of the operating system (since, in most cases, it is the OS that supplies date/time information), "localtime" and "gmtime" are really operating system interfaces. "asctime" is clearly a utility, since it can be expressed in any sufficiently expressive language in an operating-system independent fashion (note that, in fact, a portable implementation of "asctime" is published as part of the current X3J11 draft!). The same is true of "ctime" (for which a portable implementation is also published). "strftime" could also be considered a utility routine, except that it is dependent on the "locale", which is currently considerered part of the C environment. As long as the "locale" is considered part of the C environment, and *not* a part of the operating system, "strftime" should be a part of the C standard. If the ANSI C standard included a definition of low-level routines for obtaining, say, the locale's full name for a month, given a month number of that month, "strftime" could also be written in portable ANSI C and published in the X3J11 draft. It does not include any OS dependencies. I would argue that this sort of "internationalization" belongs neither in an OS standard nor in a language standard; there should be a separate standard which, like e.g. various graphics standards, has bindings for several languages and can be implemented under various OSes. I'm not sure *where* the time-related stuff (i.e., the stuff that deals with "struct tm" values) belongs, although I'd argue in favor of putting it in POSIX. Unfortunately, I don't think the time-related and internationalization stuff is going to be moved out of ANSI C, and I'm also not sure how to split the OS-related and internationalization-environment-related time handling stuff between POSIX and some C-language or other-language binding of an internationalization standard.

1 0

what should be in POSIX vs X3J11
by seismo!nbires!vianet!devine May 5, 1987

May 5, 1987

I believe the way out of this 'who should do it?' problem is to only place those functions that are uniquely OS-related into POSIX. They are 'time()' and 'stime()'. Our task would then be to decide what arguments they take and what errors are defined. X3J11 should deal with the C library functions -- those in section 3 of some Unix manuals. Additional functions can be created within the domain of X3J11 but these should not be required for POSIX. As Robert Elz and others pointed out, POSIX should be the base on which different language environments may run. Imagine how a program would be written using Pascal's date/time manipulation functions. There probably won't be an asctime() call. The difficult part is how to define how the Posix utilities (eg. date, and ls) use and display dates. This is an issue for one of the POSIX subgroups (dot 2?) not the core group. Bob Devine

1 0

Re: X3J11
by seismo!cbpavo.MIS.OH.ATT.COM!mark May 5, 1987

May 5, 1987

It sounds to me like we're all in agreement: a field in the struct tm defining the offset from GMT is what we need. Whether you call it an "adjustment" or an "offset" is just your point of view. Mark

1 0

Re: X3J11
by seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt May 5, 1987

May 5, 1987

> That is why we NEED the tm_tzadj member added to the tm structure. > >I'm not sure I follow how this follows. I agree that a tm_zone >(ie: what zone this time was converted from) is needed, but I >don't see the need for a separate time zone adjustment field. We are agreeing. There is the need for a member (whether the name is tm_zone or tm_adj as it is in HP's implementation) in the tm structure which gives the difference between GMT and localtime in seconds. This applies specifically to the time value in the tm structure. Sorry about any confusion. Ron Tolley

1 0

Re: X3J11
by Robert Elz May 5, 1987

May 5, 1987

Date: Mon, 4 May 87 11:04:30 EDT From: hplabs!hpfcla!hpfclj!hpfcdg!rgt Message-ID: <8705041525.AA23780@hpfcla> That is why we NEED the tm_tzadj member added to the tm structure. I'm not sure I follow how this follows. I agree that a tm_zone (ie: what zone this time was converted from) is needed, but I don't see the need for a separate time zone adjustment field. That is, I can't see anything rational for it to be an adjustment from. I don't believe the concept of a "standard zone" makes any sense, in general there simply is no such thing. The only number of consequence is the offset from gmt of this particular struct tm. kre

1 0

Re: X3J11
by seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt May 4, 1987

May 4, 1987

> The problem with all this is that mktime is supposed to be the > inverse of localtime, if it was the inverse of gmtime, or if it > had a zone parameter, then this kind of thing could be made to > work. But then mktime would be useless for more common functions, > especially that of hiding the timezone & dst rules from the application. Thank you for stating it so well. That is why we NEED the tm_tzadj member added to the tm structure. Ron Tolley

1 0

Re: Ballot 4 - results (really POSIX / X3J11 relationship)
by seismo!cbpavo.MIS.OH.ATT.COM!mark May 3, 1987

May 3, 1987

I thought the idea behind POSIX requiring X3J11 was that it eliminated duplication (and possible conflict) between X3J11 and POSIX. If POSIX isn't going to require X3J11, what will they overlay upon? K&R is the only other well known standard, and it's not only incredibly old, but the C library it documents is very incomplete even by 1978 standards. (I have a table I can send out if people are interested.) A lot of stuff was taken out of the /usr/group document because it was already in X3J11; does P.1003 really want to put all that stuff back in? Mark

2 1

Re: Ballot 4 - results (really POSIX / X3J11 relationship)
by seismo!hadron!jsdy May 3, 1987

May 3, 1987

To prevent runaway definitional anarchy, if POSIX includes some C language interface definitions, then oneof(X3J11,POSIX) should defer to the other. I think that POSIX deferring to X3J11 is natural, and should be done unless X3J11 gets really out of hand. Which I don't really think has happened yet. Joe

1 0

Re: Ballot 4 - results
by seismo!hadron!jsdy May 3, 1987

May 3, 1987

> I was just rereading ANSI C X3J11 and noticed that strftime and mktime > are in there. Since POSIX is a superset (by definition) of ANSI C, I should mention that even though X3J11 isn't final, and POSIX is co-operating strongly with (but not subservient to) X3J11, I wish to alter my ballot to support whatever is in X3J11, since it is or will be (it seems) the standard issued first (of the two). Joe Yao jsdy(a)hadron.COM (not yet domainised) hadron!jsdy(a){seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM} {arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

1 0

Re: Ballot 4 - results
by seismo!hadron!jsdy May 3, 1987

May 3, 1987

> POSIX will have strftime and mktime, it isn't an option. X3J11 is still a draft standard: it will go through (I hear tell) at least one more edit-RFC cycle. > Personally, I think strftime botches timezones - "hours" doesn't say > which time zone. Why, nor does ctime() at all, nor System V date. But there is, in the X3J11 strftime(), a %Z for the time zone. [ 10 Oct 1986 ] Joe Yao jsdy(a)hadron.COM (not yet domainised) hadron!jsdy(a){seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM} {arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

1 0