Date: 30 Apr 87 21:32:08 CDT (Thu) From: ahby@meccts.mecc.mn.org (Shane P. McCarron) Message-ID: <8704302132.AA14158@meccts.MECC.MN.ORG> Actually, at the working group meeting last week, we changed the definition of POSIX a little bit. I have always believed that the POSIX working group was comprised of emminently reasonable and sensible people, and this decision confirms it. Unlike X3J11 which seems to have taken off on the road of innovation, POSIX is very sensibly confining itself to standardisation. Please convey my appreciation to the group at the next meeting. The unfortunate implication of all this is that strftime and friends are not really required by the POSIX standard. I don't agree that this is unfortunate. These functions are innovation, and simply don't belong in POSIX, regardless of how useful they might be. In fact, its not clear to me that they would belong in POSIX in any case. Methods of formatting strings for output don't seem to belong in an operating systems standard. They do legitimately belong in a language standard. I know this whole issue is very much confused by the strong linage between POSIX and C. As a test whether something belongs or not, I would ask a question something like this ... "Would this still be the natural and proper way to perform the function inother (procedural) languages?" If the answer is yes, then the function properly belongs in POSIX, if no, then it belongs in the language specification. For example, the functionality of localtime() is to convert a binary internal time format to a struct containing integers representing the time. In Pascal a similar function would be natural (returning a record). In Fortran, again it would be natural to use a function for this purpose (returning an array). Similarly in Modula, Ada, Algol, etc. Strftime() taking a format string, and a struct, and producing a string containing the formatted time is a perfectly natural C operation, but isn't the way the operation would usually be expressed in other languages. In fact, its doubtful if nost other languages would have any immediate use for such an operation at all, this being more commonly performed as an output routine, with the formatted data appearing only on the external file. I confine the test to procedural languages, as the interface to POSIX is a procedural one, testing a proposed function against Smalltalk is not likely to give useful results. I think that if POSIX were to attempt to define more than is necessary for the operating system and its interface (in P1003.1) it will unnecessarily inhibit any future possibility of creating bindings for other languages. And since the POSIX Working Group decided at the December meeteing to defer to X3 in all things relating to time, the issue is a bit confused. I think this was a mistake, regardless of the dependance on X3J11. X3J11 is concerned to make sure that C programs can run in a variety of environments, not only POSIX. Because of that there are some things that they need to leave unspecified. The representation of times is one of those, they cannot really even depend on GMT being available. However, POSIX doesn't have this problem, it can, and should, specify th details of things such as exactly what a time_t is, and what range of times must be representable. So, I would appreciate it if you could suggest to the POSIX group that they reconsider that December decision, and return the fundamental operations on times to POSIX. I believe those to be a definition of time_t, the function time(), gmtime(), and localtime(). I do not really believe that asctime() (or ctime()) really belong in POSIX, though pragmatic considerations might dictate that they be included. Usage of the environment variable TZ clearly does belong. It would be nice to see (a reasonable definition of) mktime() included, however this falls into innovation, and should be left to a later revision. Robert Elz