- tz - lists.iana.org

New draft C standard
by ado Nov. 21, 1987

Nov. 21, 1987

I got the latest, November 9, 1987 draft C standard in the mail yesterday. The good news: there's a footnote telling how to get a broken-down wall clock time converted into "elapsed seconds since the epoch" (or whatever the implementation is choosing to use) *without* having to know whether the time being converted is Daylight Time or not: you're supposed to drop a -1 into the "tm_isdst" field. The bad news: this mechanism is described in a footnote, and, unfortunately, footnotes are not part of the Standard (as is explained at the start of the Standard). (There's other stuff relegated to footnotes that might better be made part of the Standard, but that's a different soapbox.) Giving a choice of lobbying to get the footnote's content moved into the Standard or dropping mktime entirely, I'd choose the second alternative, but I realize I'm getting crabbier as I get older. I've attached a transcribed version of the latest wording. --ado 4.12 DATE AND TIME <time.h> 4.12.1 Components of time The header <time.h> declares one macro, three types, and several functions for manipulating time. Many functions deal with a calendar time that represents the current date (according to the Gregorian calendar) and time. Some functions deal with local time, which is the calendar time expressed for some specific time zone, and with Daylight Saving Time, which is a temporary change in the algorithm for determining local time. The local time zone and Daylight Saving Time are implementation defined. The macro defined is CLK_TCK which is the number per second of the value returned by the clock function. The types declared are clock_t and time_t which are arithmetic types capable of representing times, and struct tm which holds the components of a calendar time, called the broken-down time. The structure shall contain at least the following members, in any order. The semantics of the members and their normal ranges are expressed in the comments. int tm_sec; /* seconds after the minute - [0,59] */ int tm_min; /* minutes after the hour - [0,59] */ int tm_hour; /* hours since midnight - [0,23] */ int tm_mday; /* day of the month - [1,31] */ int tm_mon; /* months since January - [0,11] */ int tm_year; /* years since 1900 */ int tm_wday; /* days since Sunday - [0,6] */ int tm_yday; /* days since January 1 - [0,365] */ int tm_isdst; /* Daylight Saving Time flag */ The value of tm_isdst is positive if Daylight Saving Time is in effect, zero if Daylight Saving Time is not in effect, and negative if the information is not available. 4.12.2 Time manipulation functions 4.12.2.1 The clock function [SECTION OMITTED] 4.12.2.2 The difftime function [SECTION OMITTED] 4.12.2.3 The mktime function Synopsis #include <time.h> time_t mktime(struct tm *timeptr); Description The mktime function converts the broken-down time, expressed as local time, in the structure pointed to by timeptr into a calendar time value with the same encoding as that of the values returned by the time function. The original values of the tm_wday and tm_yday components of the structure are ignored, and the original values of the 101 other components are not restricted to the ranges indicated above. On successful completion, the values of the tm_wday and tm_yday components of the structure are set appropriately, and the other components are set to represent the specified calendar time, but with their values forced to the ranges indicated above; the final value of tm_mday is not set until tm_mon and tm_year are determined. Returns The mktime function returns the specified calendar time encoded as a value of type time_t. If the calendar time cannot be represented, the function returns the value (time_t)-1. Example What day of the week is July 4, 2001? #include <stdio.h> #include <time.h> static const char *const wday[] = { "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "-unknown-" }; struct tm time_str; time_str.tm_year = 2001 - 1900; time_str.tm_mon = 7 - 1; time_str.tm_mday = 4; time_str.tm_hour = 0; time_str.tm_min = 0; time_str.tm_sec = 1; time_str.tm_isdst = -1; if (mktime(&time_str) == -1) time_str.tm_wday = 7; printf("%s\n", wday[time_str.tm_wday]); 4.12.2.4 The time function Synopsis #include <time.h> time_t time(time_t *timer); Description The time function determines current calendar time. The encoding of the value is unspecified. Returns The time function returns the implementation's best approximation to the current calendar time. The value (time_t)-1 is returned if the calendar time is not available. If timer is not a null pointer, the return value is also assigned to the object it points to. ____________ 101. A positive or zero value for tm_isdst causes the mktime function initially to presume that Daylight Saving Time, respectively, is or is not in effect for the specified time. A negative value for tm_isdst causes the mktime function to attempt to determine whether Daylight Saving Time is in effect for the specified time.

1 0

Re: August 13 C Standard Rationale on mktime
by ado Sept. 1, 1987

Sept. 1, 1987

> . . .the sole purpose of mktime is for doing arithmetic on time_t's. . . > if the caller has to set tm_isdst before calling mktime(). > The use that most people want for mktime() is to be able to parse > a string (or whatever) into the tm_hour fields, etc, and then produce > a time_t .. having to second guess whether dst applied at that particular > time is never going to work. . . Well, much of the time it will work if you're prepared to check the values that mktime drops into the "struct tm" passed to it, and if you've saved away the values you passed in. You guess one way or the other on tm_isdst and call mktime. If mktime changes tm_hour on you, you guess "the other" way and try again. Second guessing, yes; third guessing, no. Of course the Standard is mum about the need to do this, and about the need to handle other problems mentioned by kre. --ado

1 0

August 13 C Standard Rationale on mktime; seismo's retirement
by ado Sept. 1, 1987

Sept. 1, 1987

The attached material appears on pages 99 and 100 of the 13 August 1987 "Rationale for Draft Proposed American National Standard for Information Systems Programming Language C". Note that mktime is supposed to examine tm_isdst when converting a "struct tm" to a "time_t". Coding errors in previous versions of the Rationale have also been corrected, although I believe that the when = *localtime(now); line should read when = *localtime(&now); Seismo's retirement from the mail forwarding business makes it unlikely that the time zone mailing list can be continued; this should not be a problem since volume has been nonexistent of late. If all else fails, try comp.std.c. --ado 4.12.2.3 The mktime function mktime was invented by the Committee to complete the set of time functions. With this function it becomes possible to perform portable calculations involving clock times and broken-down times. The rules on the ranges of the fields within the *timeptr record are crafted to permit useful arithmetic to be done. For instance, here is a paradigm for continuing some loop for an hour: #include <time.h> struct tm when; time_t now; time_t deadline; /* ... */ now = time(0); when = *localtime(now); when.tm_hour += 1; /* result is in the range [1,24] */ deadline = mktime(&when); printf("Loop will finish: %s\n", asctime(&when)); while (difftime(time(0), deadline) > 0) whatever(); The specification of mktime guarantees that the addition to the tm_hour field produces the correct result even when the new value of tm_hour is 24, i.e., a value outside the range ever returned by a library function in a struct tm object. One of the reasons for adding this function is to replace the capability to do such arithmetic which is lost when a programmer cannot depend on time_t being an integral multiple of some known time unit. Several readers of earlier versions of this Rationale have pointed out apparent problems in this example if now is just before a transition into or out of daylight saviings time. However, when.tm_isdst tags what sort of time was the basis of the calculation. Implementors, take heed.

2 1

Re: Timezone stuff and System V Verification Suite
by ado Aug. 7, 1987

Aug. 7, 1987

The problem at hand: the mod.sources version of the time zone compiler sets tzname[1] to "EWT" for the Eastern US; this causes problems with SVVS. I had a realization this morning. A while back I added a "-s" flag to the time zone compiler to let folks produce time zone information files with whose time(2) values were limited to numbers that have the same value whether you take them to be signed or unsigned. This was done to let time zone files be used in network setups where some machines on the network wanted to have signed time_t's and others wanted to have unsigned time_t's. Providentially, if you use the -s option you should get files that let localtime be SVVS compliant. Not only is this in line with kre's suggestion that the work should be done in the compiler rather than in localtime--it's already in place. I've attached diffs for zic.c and zic.8; apologies to those who've seen them before (but note that I've added a new note about SVVS to zic.8). --ado ------------------------------------------------------------------------------- *** 3.1/zic.c Fri Aug 7 10:42:22 1987 --- 3.6/zic.c Fri Aug 7 10:42:39 1987 *************** *** 4,10 **** #ifndef lint #ifndef NOID ! static char sccsid[] = "@(#)zic.c 3.1"; #endif /* !NOID */ #endif /* !lint */ --- 4,10 ---- #ifndef lint #ifndef NOID ! static char sccsid[] = "@(#)zic.c 3.6"; #endif /* !NOID */ #endif /* !lint */ *************** *** 355,361 **** usage() { (void) fprintf(stderr, ! "%s: usage is %s [ -v ] [ -l localtime ] [ -d directory ] [ filename ... ]\n", progname, progname); exit(1); } --- 355,361 ---- usage() { (void) fprintf(stderr, ! "%s: usage is %s [ -s ] [ -v ] [ -l localtime ] [ -d directory ] [ filename ... ]\n", progname, progname); exit(1); } *************** *** 362,367 **** --- 362,368 ---- static char * lcltime = NULL; static char * directory = NULL; + static int sflag = FALSE; main(argc, argv) int argc; *************** *** 374,380 **** umask(umask(022) | 022); #endif progname = argv[0]; ! while ((c = getopt(argc, argv, "d:l:v")) != EOF) switch (c) { default: usage(); --- 375,381 ---- umask(umask(022) | 022); #endif progname = argv[0]; ! while ((c = getopt(argc, argv, "d:l:vs")) != EOF) switch (c) { default: usage(); *************** *** 401,406 **** --- 402,410 ---- case 'v': noise = TRUE; break; + case 's': + sflag = TRUE; + break; } if (optind == argc - 1 && strcmp(argv[optind], "=") == 0) usage(); /* usage message by request */ *************** *** 465,470 **** --- 469,476 ---- tt_signed = FALSE; min_time = 0; max_time = ~(time_t) 0; + if (sflag) + max_time >>= 1; } else { tt_signed = TRUE; min_time = bit; *************** *** 471,476 **** --- 477,484 ---- max_time = bit; ++max_time; max_time = -max_time; + if (sflag) + min_time = 0; } min_year = TM_YEAR_BASE + gmtime(&min_time)->tm_year; max_year = TM_YEAR_BASE + gmtime(&max_time)->tm_year; *************** *** 687,693 **** inrule(fields, nfields) register char ** fields; { ! struct rule r; if (nfields != RULE_FIELDS) { error("wrong number of fields on Rule line"); --- 695,701 ---- inrule(fields, nfields) register char ** fields; { ! static struct rule r; if (nfields != RULE_FIELDS) { error("wrong number of fields on Rule line"); *************** *** 757,763 **** register char ** fields; { register char * cp; ! struct zone z; register int i_gmtoff, i_rule, i_format; register int i_untilyear, i_untilmonth; register int i_untilday, i_untiltime; --- 765,771 ---- register char ** fields; { register char * cp; ! static struct zone z; register int i_gmtoff, i_rule, i_format; register int i_untilyear, i_untilmonth; register int i_untilday, i_untiltime; ------------------------------------------------------------------------------- *** 3.1/zic.8 Fri Aug 7 10:41:29 1987 --- 3.4/zic.8 Fri Aug 7 10:41:32 1987 *************** *** 12,17 **** --- 12,19 ---- .B \-l .I localtime ] [ + .B \-s + ] [ .I filename \&... ] .SH DESCRIPTION *************** *** 43,48 **** --- 45,55 ---- of years representable by .IR time (2) values. + .TP + .B \-s + Limit time values stored in output files to values that are the same + whether they're taken to be signed or unsigned. + You can use this option to generate SVVS-compatible files. .sp Input lines are made up of fields. Fields are separated from one another by any number of white space characters. *************** *** 98,104 **** field. .TP .B TYPE ! Gives the type of year in which the year applies. If .B TYPE is --- 105,111 ---- field. .TP .B TYPE ! Gives the type of year in which the rule applies. If .B TYPE is *************** *** 155,161 **** field. .TP .B AT ! Gives the time of day at which the rule takes affect. Recognized forms include: .nf .in +.5i --- 162,168 ---- field. .TP .B AT ! Gives the time of day at which the rule takes effect. Recognized forms include: .nf .in +.5i *************** *** 291,294 **** /etc/zoneinfo standard directory used for created files .SH "SEE ALSO" newctime(3), tzfile(5), zdump(8) ! .. @(#)zic.8 3.1 --- 298,301 ---- /etc/zoneinfo standard directory used for created files .SH "SEE ALSO" newctime(3), tzfile(5), zdump(8) ! .. @(#)zic.8 3.4

1 0

Re: Timezone stuff and System V Verification Suite
by seismo!scubed!ncr-sd!ncrcae!sauron!wescott July 24, 1987

July 24, 1987

> I think the "right" fix is to remove the "Link" lines from the > "northamerica" file (which provides the EST5EDT aliases) and > put them in the "systemv" file, where the data should be an > accurate System V emulation. > ... > Or perhaps the "blessed" 2 zone names should be marked in the > data file to avoid surprises. That's an idea. We (NCR) are really looking for the best of both worlds. We like the flexibility of the PD ctime but need to pass the SVVS as well as provide compatibility for existing customers. The only problem has been that of tzname(). > Both the Sys V and BSD standard timezone name stuff is trash, > it all needs to be discarded completely. And the matter gets worse with SysVr3v1 (from ctime(3c) man page): [start of quote] tzset() uses the contents of the environment variable TZ to override the value of the different external variables. The syntax of TZ can be described as follows: TZ -> zone | zone signed_time | zone signed_time zone | zone signed_time zone dst zone -> letter letter letter signed_time -> sign time | time time -> hour | hour : minute | hour : minute : second dst -> signed_time | signed_time ; dst_date , dst_date | ; dst_date , dst_date dst_date -> julian | julian / time [...] For example, the setting for New Jersey in 1986 could be "EST5EDT4;117/2:00:00,299/2:00:00" [...] A southern hemisphere setting such as the Cook Islands could be "KDT9:30KST10:00;64/5:00,303/20:00" [end of quote] There is a new extern long to go along with timezone called "altzone" which holds the value of the daylight saving time "timezone" offset. The SVID, however, does not reflect this "improvement" nor apparently will the SVVS. The "Future Directions" section of the SVID does mention the fractional hours/sign component in the middle of the TZ variable. The ctime(3c) man page also describes two new routines that allow user control of the formatting of the string as well as using non-english names (under the control of the env. var. LANGUAGE). -Mike Wescott wescott(a)ncrcae.Columbia.NCR.COM

2 1

Timezone stuff and System V Verification Suite
by ado July 19, 1987

July 19, 1987

Here are excerpts from two notes from Mike Wescott (wescott(a)ncrcae.Columbia.NCR.COM) I'd appreciate comments on the changes Mike suggests. (Lines preceded by "> " in the second note are Mike quoting me.) --ado Date: Thu, 9 Jul 87 15:29:36 pdt Message-Id: <8707092229.AA00730(a)SCUBED.ARPA> Subject: Re: v08i085: Public Domain localtime We have uncovered a problem with the PD ctime with respect to the System V Verification Suite and SVID compatibility. The problem is with tzset(). Try the little program, xxx.c: #include <time.h> main() { tzset(); printf("%s\n%s\n", tzname[0], tzname[1]); } and try the following: TZ=PST8PDT ./xxx it produces: PST PWT and TZ=EST5EDT ./xxx produces EST EWT The problem is that tzname[1] become the (obsolete) EWT. The fix, I believe, would be to use the most recently used abbreviations to the value of time(0). Diff for such a fix follows and passes SVVS. -Mike Wescott wescott(a)ncrcae.Columbia.NCR.COM *** localtime.c.or Thu Jul 9 09:57:27 1987 --- localtime.c Thu Jul 9 14:31:38 1987 *************** *** 90,95 **** --- 90,96 ---- { register int i; register int fid; + time_t now; if (name == 0 && (name = TZDEFAULT) == 0) return -1; *************** *** 182,191 **** timezone = -s.ttis[0].tt_gmtoff; daylight = 0; #endif /* USG_COMPAT */ ! for (i = 1; i < s.typecnt; ++i) { register struct ttinfo * ttisp; ! ! ttisp = &s.ttis[i]; if (ttisp->tt_isdst) { tzname[1] = &s.chars[ttisp->tt_abbrind]; #ifdef USG_COMPAT --- 183,194 ---- timezone = -s.ttis[0].tt_gmtoff; daylight = 0; #endif /* USG_COMPAT */ ! now = time(0); ! for (i = 1; i < s.timecnt; ++i) { register struct ttinfo * ttisp; ! if (now < s.ats[i]) ! break; ! ttisp = &s.ttis[s.types[i]]; if (ttisp->tt_isdst) { tzname[1] = &s.chars[ttisp->tt_abbrind]; #ifdef USG_COMPAT ------------------------------------------------------------------------------- Date: Tue, 14 Jul 87 07:22:19 pdt Message-Id: <8707141422.AA27049(a)SCUBED.ARPA> Subject: Re: v08i085: Public Domain localtime > Many thanks for the note on the problem with SVVS. > Would it be all right with you if I passed the note on to other interested > folks? No problem, I sent it to you with that in mind. The code could probably be made a little more efficient but it shouldn't have to run too often. > Also--the time zone files described in the "systemv" file were designed to > provide System V compatibility. It looks as if you're in a position to check > on whether they actually do; if you could, I'd appreciate it. We ran SVVS (SysVr2 not r3 yet) and the only thing it complained about was the problem with the tzset() function. We are compiling with USG, USG_COMPAT, and STD_INSPIRED defined. I'll check the "systemv" file but it doesn't seem to be problem as far as SVVS goes.

2 1

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

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

Re: Ballot 4 - results
by seismo!meccts.mecc.mn.org!ahby May 2, 1987

May 2, 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, > POSIX will have strftime and mktime, it isn't an option. Actually, at the working group meeting last week, we changed the definition of POSIX a little bit. X/OPEN had some reservations about POSIX requiring X3J11, because it would increase the time before there could be conforming systems. Also, a number of people from different implementors felt that when their companies had signed onto the POSIX concept, they had not necessarily bought into X3. These same people also said that they were planning on providing an X3 conforming environment, but not in the same timeframe as POSIX. As a result of these discussions, we redefined the terms CONFORMING APPLICATION and CONFORMING PORTABLE APPLICATION. The new names are PORTABLE APPLICATION USING EXTENSIONS and POSIX CONFORMING <language> APPLICATION. The text of these definitions is: Portable Application Using Extensions A Portable Application Using Extensions shall meet the following requirements: All extensions beyond those permitted to a Posix Conforming Language Application and the corresponding language shall be clearly documented. The application developer documents all application requirements for the operating environment that are implementation dependent including <limits.h> S2.9 characteristics and other related configuration requirements (linear address space, file store requirements, etc.) POSIX Conforming Applications POSIX Conforming Standard C Language Application A POSIX Conforming Standard C Language Application is a strictly conforming program, as defined in the ANSI/X3.159-198x standard, which utilizes only those extensions as described by the service bindings in this standard. In addition, a POSIX Conforming Standard C Language Application shall not depend on any unspecified, undefined, or implementation defined behavior, nor shall it require that any symbolic constant in <limits.h> S2.9 be outside its most restrictive value. As a result of these changes, it is possible to have a Conforming Implementation of POSIX that does not supply an X3 conforming environment. What environment it does provide is unspecified at this time, but the P1003.1 Working Group expects to see something from X/OPEN about a K&R C Language binding, which uses the X/OPEN Portability Guide as the basis for the C Language and its libraries. The unfortunate implication of all this is that strftime and friends are not really required by the POSIX standard. 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. -- Shane P. McCarron UUCP ihnp4!meccts!ahby, ahby(a)MECC.MN.ORG MECC Technical Services ATT (612) 481-3589 Secretary, IEEE P1003.1

2 1

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

May 1, 1987

> Ignoring the coding and grammar errors in the Rationale, > the big problem here is that code like the Rationale's > > when = *localtime(now); > when.tm_hour += 1; > deadline = mktime(when); > > printf("Loop will finish: %s\n", asctime(when)); > while (difftime(time(0), deadline) > 0) whatever(); > > is *not* "a paradigm for continuing some loop for an hour." > The code may continue for two hours (or not at all) > if it is executed just before a daylight saving time transition. How? deadline is a time_t (GMT) and so is time(0). Mark

2 1

Re: X3J11
by ado May 1, 1987

May 1, 1987

> > . . .the big problem here is that code like the Rationale's > > > > when = *localtime(now); > > when.tm_hour += 1; > > deadline = mktime(when); > > > > printf("Loop will finish: %s\n", asctime(when)); > > while (difftime(time(0), deadline) > 0) whatever(); > > > > is *not* "a paradigm for continuing some loop for an hour." > > The code may continue for two hours (or not at all) > > if it is executed just before a daylight saving time transition. > How? deadline is a time_t (GMT) and so is time(0). (I hope I don't end up with egg all over my face on this one!) First, assume that it's 1:30:00 a.m. on a "spring forward" day when we execute the when = *localtime(now); statement. We next do a when.tm_hour += 1; which sets when.tm_hour to 2. We then execute the deadline = mktime(when); statement to answer the question "At what elapsed time in seconds since 1970 will my wall clock read 2:30 a.m.?" Since mktime knows we're springing forward, it returns -1 as a way of saying "There is no such time today." This means that the test in the while (difftime(time(0), deadline) > 0) whatever(); line will *always* succeed--so "whatever" will never be called. (Side questions: does this say anything about whether time_t should be signed? Does it say anything about extra checking difftime should do?) Now assume that it's 1:30:00 a.m. (for the first time :-) on a "fall back" day when we execute the when = *localtime(now); statement. Again we when.tm_hour += 1; deadline = mktime(when); to learn when our local wall clock will read 2:30 a.m. But that won't be until two hours from "now", so the loop will run twice as long as we might expect. --ado

1 0

Re: testing
by seismo!!dlm May 1, 1987

May 1, 1987

Yes, I am there I haven't seen or heard a word from the Time Mailing List in weeks! My mail address is {ihnp4,cbosgd,attunix,cbatt}!cuuxb!dlm. Maybe we're not polling cbosgd or cbatt but I thought so. -- =Dennis L. Mumaugh Lisle, IL ...!{ihnp4,cbosgd,lll-crg}!cuuxb!dlm

1 0