May 1987 - tz - lists.iana.org

Re: what should be in POSIX vs X3J11
by seismo!celerity!dreamit!jjw May 19, 1987

May 19, 1987

In response to mail from seismo!nbires!vianet!devine Sat May 9 10:19:15 1987 > In my last message I proposed dividing the many date/time related > functions by the rule of 'is it Unix-based or language-based?'. And I > meant by a call being in Man Section 3 as roughly the same as the latter. I don't think the division should be based on whether the function is documented in section 2 or 3 of the Unix manual, that is mostly an artifact of the Unix implementation. Instead, Something should be placed into X3J11 based on whether a standard conforming C program should be able to use the function. Something should be placed into the POSIX standard based on whether all programs running under a conforming operating system should be able to use the function. In general I think POSIX should restrict itself to low level functions (such as "time()") and should avoid specifying higher level functions (such as "ctime()"). X3J11, however, should specify both low and high level functions where that makes sense. Because of the relationship between C and Unix there will be a lot of overlap between these two and every effort should be made to keep them the same. I believe this mailing list is a reasonable place to discuss whether the various timing functions belong in X3J11, POSIX or both. It will then be up to those who are members of the standards committees to bring any results of such a discussion to the attention of the committees. I would organize "time" functions as follows: POSIX only both X3J11 only stime() time()** everything else utime()* times() time_t The reason for leaving stime() out of X3J11 is that setting a system wide time and date is not something that is done by many programs and The reason for leaving utime() out of X3J11 is that the implications of and reasons for setting file times is likely to be operating systems dependant. It is also possible to argue that if programs can read these values they should be able to set them too. * file access times (what they are and when they are set) is probably outside the purview of this mailing list. ** POSIX should probably have a "gettimeofday" call which provides better granularity than seconds. ftime() has the problem of including timezone information which I don't believe belongs in the operating system interface. -- J. J. Whelan

1 0

Colorado DST info
by seismo!nbires!vianet!devine May 19, 1987

May 19, 1987

The full state House has passed a resolution to have year-round DST for Colorado. The proposal to move the state to Central time was defeated. Basically, the argument against this second proposal boiled down to "This state has mountains. Why should we move out of the Mountain timezone?". The State Senate must approve the resolution before the US Dept of Transportation will be asked to approve it. Bob

1 0

POSIX & X3J11
by seismo!meccts.mecc.mn.org!ahby May 11, 1987

May 11, 1987

In a recent posting, Mark notes that this group has no real pull with either standards body, and that they will decide what they decide. Well, although I cannot speak for X3J11 (I am a voting member, but do not have time to attend the meetings), I can say that IEEE P1003.1 is always interested in any contributions that ANY group or individual cares to make. I have been recording most of the discussion about what items you think should be where, and I am willing to submit these to the Working Group for consideration at the June meeting in Seattle. However, time is short! (no pun intended). The June meeting is the 22nd, and that is the LAST meeting before full ballot will take place. Although anyone may comment after the standard goes to ballot, balloting objections will get first consideration after we go full use ballot. Right now, all comments are being considered. I know the reasons why the time stuff was dropped from the draft some meetings ago (I believe it was in September), and personally think that they were not good reasons. I believe that the group would really welcome a formal propsal with specific language for some time functions. I strongly recommend that some or all of the people on this mailing list get together and draft such a proposal. --- Shane P. McCarron UUCP ihnp4!meccts!ahby, ahby(a)MECC.MN.ORG MECC Technical Services ATT (612) 481-3589 (C) Copyright 1987 Shane P. McCarron Redistribution allowed only if your recipients can redistribute

1 0

Re: what should be in POSIX vs X3J11
by seismo!cbpavo.MIS.OH.ATT.COM!mark May 10, 1987

May 10, 1987

I guess I have a fundamental problem with this whole discussion. This mailing list is not, as far as I know, officially sanctioned by either X3J11 or P1003. We can pontificate all we want about what belongs in ANSI C or in POSIX, but these decisions are made by X3J11 and P1003, not by us. Other than being interested in time zone issues, do we really have any kind of sanction, delegation, or authority from either committee? Mark

1 0

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

May 9, 1987

Unix and C are very tightly interwoven. Trying to separate them to form two standards is very much a Gordian (Ritchian?) Knot. In my last message I proposed dividing the many date/time related functions by the rule of 'is it Unix-based or language-based?'. And I meant by a call being in Man Section 3 as roughly the same as the latter. This message has more detail. Putting the choices into columns: Unix-based either-one language-based time() ftime() asctime() times() tzset() ctime() stime() time_t gmtime() utime() localtime() difftime() mktime() struct tm X3J11's date formatting functions Do these groupings make sense? Where should the 'either-one' functions be placed? Arguments can be made for putting them on both ends of the spectrum. Here are a couple of examples to show how various vendors with wildly different OSs dealt with the problem of what to put in their C libraries. VMS: Base OS has a 64-bit representation of time that is the number of 100 nanoseconds periods since 00:00 on November 17, 1858. HAS: ctime(), ftime() [but TZ and DST are zero], localtime() [isdst=0] time() [seconds since 00:00 UT 1/1/70], and times() [the sys fields=0] MISSING: asctime(), gmtime(), stime(), utime() DOS: Base OS keeps track of time since 1/1/80 HAS: asctime(), ctime(), difftime(), ftime(), gmtime(), localtime(), tzset(), time() [returns seconds since 00:00 UT 1/1/70], utime(), and times() MISSING: stime() DOS's functions won't give back a formatted string for any time before 1/1/80, ie, long t=12345; ctime(&t) gives back 1/1/80 even though t is referring to a day in 1970.

1 0

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