March 1987 - tz - lists.iana.org

Re: Addition to Arthur Olsen/4.3bsd table-driven ctime
by seismo!berkeley.edu!bostic%okeeffe March 31, 1987

March 31, 1987

> I cannot be sure that my customers will install the necessary > timezone support files. Therefore, any copy of ctime linked into > my programs must work "correctly" when transported to a machine > without /etc/zoneinfo in place. Neither can you be sure that they will install /etc/passwd. You don't handle that, why handle this? Not that I think that defaulting to GMT is correct, I don't. However, I can trivially fix it so that worst case is off by an hour. Which seems sufficient. > I insist that both timezone and DST corrections be applied, even in > the absence of /etc/zoneinfo, which means that ctime must carry > some DST information along in its data segment, so it can perform > at least as well as it used to. This is unclear to me. > The next question is, should any DST information hard-compiled > into ctime be fixed to reflect recent changes? The surprising > answer is "no." That means that your worst case is off by an hour. (Ignoring double DST.) The same as 4.3's. What am I missing? --keith > Steve Summit > stevesu(a)copper.tek.com

1 0

Addition to Arthur Olsen/4.3bsd table-driven ctime
by seismo!rutgers!lll-lcc!cae780!tektronix.TEK.COM!copper.TEK.COM!stevesu March 30, 1987

March 30, 1987

(This is essentially the article I just posted to comp.unix.wizards and comp.bugs.4bsd). First, let me thank you guys for the work that has gone into this new ctime. A table-driven approach is clearly the only way to go, and this one works admirably well. (I can't believe how fast it is, and how small both ctime.o and the zoneinfo files are.) I foresee one problem with its use, however, which I'll describe, along with a proposed solution. Suppose I'm a software vendor (which I am, or at least I work for one), and I ship binary executables to my customers (which I do), executables which reference ctime and friends (which they do). What, if anything, should I do to ctime on my development system? I cannot be sure that my customers will install the necessary timezone support files. Therefore, any copy of ctime linked into my programs must work "correctly" when transported to a machine without /etc/zoneinfo in place. The version posted to net.sources defaulted to GMT in the absence of /etc/zoneinfo. The "Official 4.3BSD" version posted last week arranges that local timezone correction be applied in this situation, based on the kernel's notion of the timezone. I insist that both timezone _a_n_d DST corrections be applied, even in the absence of /etc/zoneinfo, which means that ctime must carry some DST information along in its data segment, so it can perform at least as well as it used to. The next question is, should any DST information hard-compiled into ctime be fixed to reflect recent changes? The surprising answer is "no." For sites which have installed /etc/zoneinfo, the up-to-date tables found there will take precedence. At sites without /etc/zoneinfo, the safest assumption is that they have not really dealt with the ctime problem at all, but are tweaking the system clock (in the case of the upcoming change in the US, setting the clock ahead one hour on April 5, and setting it back an hour on April 26, when the old ctime thinks DST kicks in). Such a strategy is reasonable, and works fine as long as the DST correction applied by date(1) when the internal GMT is set matches the correction applied by each and every program when GMT is converted back to local time. An executable with a "fixed" version of ctime would in fact behave incorrectly at such a site. Therefore, the DST information hard-coded into any improved version of ctime must be exactly as broken as the old, "standard" one. In that way, it will work equally well on systems that have done no more to deal with the DST change than changing their clocks for three weeks, and on systems that have adopted the proposed fix. (The only flaw in this theory is the possibility that people on some systems have prolonged their agony by going to the trouble of relinking everything, but with a "fixed" ctime that still relies only on compiled-in tables. This approach is in fact the one suggested by Keith Bostic's "ARTICLE 13." If anybody is considering this, take my advice and don't. If you're in a position to relink at all, it's really no more trouble to use the table-driven ctime, and that way you won't have to worry the next time the DST rules change.) Herewith are context diffs, against the 4.3 version posted by Keith Bostic last week, of a version of the Arthur Olsen ctime that works in a backwards-compatible way in the absence of /etc/zoneinfo. (I am also posting the complete, modified version to net.sources.) The code actually uses the same DST tables as the old 4.1/4.2 ctime, to guarantee compatibility. The old-style tables are automatically converted into the internal state lists needed by the new ctime's algorithm. (These diffs still reflect some debugging code I added, to verify that my new code was building correct internal data structures. I did regression tests against real state lists created by zic from a kludged-up description file reflecting the old transition dates.) I should point out that I have not tested the new code in the southern hemisphere case, and I suspect that it will get things wrong there for the first four months of 1970. (This code only attempts to perform DST correction after 1970, anyway. In that respect, it may be incompatible with the old ctime, which applied DST in years prior to 1970 if you passed it a negative time. The type of the internal variables has been bouncing back and forth between `long' and `unsigned long' as people try to decide how it should work.) While working over ctime, I came up with a couple of questions: In asctime, shouldn't the year really be printed with %4d (or maybe %-4d) so that the returned string is guaranteed to have its advertised 26-character length? (I realize that the code is lifted directly from the X3J11 draft standard, and that %d will only get it wrong for dates in the middle ages that a 32-bit time_t can't begin to reach. On the other hand, asctime gets handed a broken-down tm struct, so early years are quite possible.) Shouldn't the offtime() routine be declared static? It's not a publicized interface. Steve Summit stevesu(a)copper.tek.com *** ctime.orig.c Sun Mar 29 16:11:46 1987 --- ctime.c Mon Mar 30 11:27:22 1987 *************** *** 215,220 #endif /* USG_COMPAT */ } } return 0; } --- 215,223 ----- #endif /* USG_COMPAT */ } } + #ifdef DEBUG + printstate(); + #endif return 0; } *************** *** 218,223 return 0; } static tzsetkernel() { --- 221,244 ----- return 0; } + #ifdef DEBUG + + printstate() + { + int i; + + printf("TS/DST info state:\n"); + for(i = 0; i < s.timecnt; i++) + printf("time %d: %ld %d\n", i, s.ats[i], s.types[i]); + for(i = 0; i < s.typecnt; i++) + printf("type %d: %ld %d %d (%s)\n", i, + s.ttis[i].tt_gmtoff, s.ttis[i].tt_isdst, + s.ttis[i].tt_abbrind, + s.chars + s.ttis[i].tt_abbrind); + } + + #endif + static tzsetkernel() { *************** *** 224,229 struct timeval tv; struct timezone tz; char *tztab(); if (gettimeofday(&tv, &tz)) return -1; --- 245,251 ----- struct timeval tv; struct timezone tz; char *tztab(); + static dstsetkernel(); if (gettimeofday(&tv, &tz)) return -1; *************** *** 227,233 if (gettimeofday(&tv, &tz)) return -1; ! s.timecnt = 0; /* UNIX counts *west* of Greenwich */ s.ttis[0].tt_gmtoff = tz.tz_minuteswest * -SECS_PER_MIN; s.ttis[0].tt_abbrind = 0; (void)strcpy(s.chars, tztab(tz.tz_minuteswest, 0)); --- 249,257 ----- if (gettimeofday(&tv, &tz)) return -1; ! s.timecnt = 0; ! s.typecnt = 1; ! /* UNIX counts *west* of Greenwich */ s.ttis[0].tt_gmtoff = tz.tz_minuteswest * -SECS_PER_MIN; s.ttis[0].tt_isdst = 0; s.ttis[0].tt_abbrind = 0; *************** *** 229,234 return -1; s.timecnt = 0; /* UNIX counts *west* of Greenwich */ s.ttis[0].tt_gmtoff = tz.tz_minuteswest * -SECS_PER_MIN; s.ttis[0].tt_abbrind = 0; (void)strcpy(s.chars, tztab(tz.tz_minuteswest, 0)); tzname[0] = tzname[1] = s.chars; --- 253,259 ----- s.typecnt = 1; /* UNIX counts *west* of Greenwich */ s.ttis[0].tt_gmtoff = tz.tz_minuteswest * -SECS_PER_MIN; + s.ttis[0].tt_isdst = 0; s.ttis[0].tt_abbrind = 0; (void)strcpy(s.chars, tztab(tz.tz_minuteswest, 0)); tzname[0] = tzname[1] = s.chars; *************** *** 236,241 timezone = tz.tz_minuteswest * 60; daylight = tz.tz_dsttime; #endif /* USG_COMPAT */ return 0; } --- 261,274 ----- timezone = tz.tz_minuteswest * 60; daylight = tz.tz_dsttime; #endif /* USG_COMPAT */ + + if(tz.tz_dsttime) + dstsetkernel(&tz); + + #ifdef DEBUG + printstate(); + #endif + return 0; } *************** *** 386,389 tmp->tm_zone = ""; tmp->tm_gmtoff = offset; return tmp; } --- 419,615 ----- tmp->tm_zone = ""; tmp->tm_gmtoff = offset; return tmp; + } + + /* + * Backwards-compatible DST information tables. + * + * The tables give the day number of the first day after the + * Sunday of the change. + * + * DO NOT FIX THESE TABLES. + * Yes, they're wrong in several ways, including 1987 and beyond + * in the United States, but they happen to match the old ctime.c + * that is compiled into virtually all programs under 4.2bsd- + * derived systems. This is important if programs compiled with + * this version of ctime are to work correctly when shipped (in + * binary form) to systems which have not upgraded to the + * /etc/zoneinfo scheme. + * + * These hardwired tables are only used when /etc/zoneinfo cannot + * be accessed. A system which does not have /etc/zoneinfo is + * probably handling DST fluctuations by changing the system clock. + * Therefore, all programs on such a system (whether linked with + * old or new versions of ctime) must use the same DST rules. + * On a system with old-fashioned versions of ctime, handling + * DST fluctuations by changing the system clock, a "correct" + * version of ctime would in fact display incorrect results. + */ + + struct dstab { + int dayyr; + int daylb; + int dayle; + }; + + static struct dstab usdaytab[] = { + 1974, 5, 333, /* 1974: Jan 6 - last Sun. in Nov */ + 1975, 58, 303, /* 1975: Last Sun. in Feb - last Sun in Oct */ + 0, 119, 303, /* all other years: end Apr - end Oct */ + }; + + static struct dstab ausdaytab[] = { + 1970, 400, 0, /* 1970: no daylight saving at all */ + 1971, 303, 0, /* 1971: daylight saving from Oct 31 */ + 1972, 303, 58, /* 1972: Jan 1 -> Feb 27 & Oct 31 -> dec 31 */ + 0, 303, 65, /* others: -> Mar 7, Oct 31 -> */ + }; + + /* + * The European tables ... based on hearsay + * Believed correct for: + * WE: Great Britain, Ireland, Portugal + * ME: Belgium, Luxembourg, Netherlands, Denmark, Norway, + * Austria, Poland, Czechoslovakia, Sweden, Switzerland, + * DDR, DBR, France, Spain, Hungary, Italy, Jugoslavia + * Eastern European dst is unknown, we'll make it ME until someone speaks up. + * EE: Bulgaria, Finland, Greece, Rumania, Turkey, Western Russia + */ + + static struct dstab wedaytab[] = { + 1983, 86, 303, /* 1983: end March - end Oct */ + 1984, 86, 303, /* 1984: end March - end Oct */ + 1985, 86, 303, /* 1985: end March - end Oct */ + 0, 400, 0, /* others: no daylight saving at all ??? */ + }; + + static struct dstab medaytab[] = { + 1983, 86, 272, /* 1983: end March - end Sep */ + 1984, 86, 272, /* 1984: end March - end Sep */ + 1985, 86, 272, /* 1985: end March - end Sep */ + 0, 400, 0, /* others: no daylight saving at all ??? */ + }; + + static struct dayrules { + int dst_type; /* number obtained from system */ + int dst_hrs; /* hours to add when dst on */ + struct dstab * dst_rules; /* one of the above */ + enum {STH,NTH} dst_hemi; /* southern, northern hemisphere */ + } dayrules [] = { + DST_USA, 1, usdaytab, NTH, + DST_AUST, 1, ausdaytab, STH, + DST_WET, 1, wedaytab, NTH, + DST_MET, 1, medaytab, NTH, + DST_EET, 1, medaytab, NTH, /* XXX */ + -1, + }; + + static + dstsetkernel(tzp) + struct timezone *tzp; + { + struct dayrules *drp; + int tabsize; + int timei; + int y; + int yleap; + int i; + int d, di; + time_t t; + int daylb, dayle; + char *p; + + for(drp = dayrules; drp->dst_type >= 0; drp++) + if(drp->dst_type == tzp->tz_dsttime) + break; + + if(drp->dst_type < 0) + return; + + /* this ends up computing tabsize - 1, but that's what we want */ + + for(tabsize = 0; drp->dst_rules[tabsize].dayyr > 0; tabsize++) + ; + + /* 2038 is the year that signed 32 bit time_t's give out */ + + for(y = 1970, d = 0, t = 0, timei = 0; y < 2038; y++) { + daylb = drp->dst_rules[tabsize].daylb; + dayle = drp->dst_rules[tabsize].dayle; + + for(i = 0; i < tabsize; i++) + if(y == drp->dst_rules[i].dayyr) { + daylb = drp->dst_rules[i].daylb; + dayle = drp->dst_rules[i].dayle; + break; + } + + yleap = isleap(y); + + if(yleap) { + if(daylb >= 58) + daylb++; + + if(dayle >= 58) + dayle++; + } + + /* + * January 1, 1970 was a Wednesday. + * d is the difference between January 1 of the loop + * year (y) and January 1, 1970, in days. + * daylb and dayle are (0-origin) day offsets with + * respect to January 1. + * So (d + dayl[be] - 3) % 7 is the day (0 == Sunday) + * of daylb or dayle. + * That's also the number to subtract from daylb or + * dayle to get the day number (since January 1 of + * the loop year) of the preceding Sunday. + */ + + daylb -= (d + daylb - 3) % 7; + dayle -= (d + dayle - 3) % 7; + + s.ats[timei] = t + SECS_PER_DAY * daylb + + tzp->tz_minuteswest * SECS_PER_MIN + + 2 * SECS_PER_HOUR; + + s.ats[timei + 1] = t + SECS_PER_DAY * dayle + + tzp->tz_minuteswest * SECS_PER_MIN + + (drp->dst_hemi == NTH ? 1 : 2) + * SECS_PER_HOUR; + + if(drp->dst_hemi == NTH) { + s.types[timei] = tzp->tz_dsttime; + s.types[timei + 1] = 0; + } else { + s.types[timei] = 0; + s.types[timei + 1] = tzp->tz_dsttime; + } + + timei += 2; + + di = year_lengths[yleap]; + + d += di; + t += di * SECS_PER_DAY; + } + + s.timecnt = timei; + + s.ttis[1].tt_gmtoff = tzp->tz_minuteswest * -SECS_PER_MIN + + drp->dst_hrs * SECS_PER_HOUR; + + s.ttis[1].tt_isdst = tzp->tz_dsttime; + + for(p = s.chars; *p != '\0'; p++) + ; + + (void)strcpy(++p, tztab(tzp->tz_minuteswest, tzp->tz_dsttime)); + + s.ttis[1].tt_abbrind = p - s.chars; + + tzname[1] = p; + + s.typecnt = 2; }

1 0

Re: Berkeley variant of time zone stuff
by seismo!sun!guy March 30, 1987

March 30, 1987

The reason I put that code in was because I actually had the code running on a machine that I couldn't put the /etc/zoneinfo directory on. And, for a couple of days, I got a first hand look at what happens when things are 8 hours off. With the current code, it would require a major kernel problem to be more than an hour off. Isn't that worth having? Well, I don't know that it's that much better to be one hour off than 8 hours off. Also, there are plenty of files that, if missing or inaccessible, will cause UNIX some amount of distress; I'm not sure the time zone files are worth singling out. (E.g., why not put code into "init" so that the system will work even if "getty" is missing or won't work? Why not put code into the kernel to try opening "/dev/console" and running "/bin/sh" if "/etc/init" can't be found?) In Olson's scheme, if the time zone files are inaccessible, it will be pretty obvious and the administrator will find those files, by hook or by crook. I don't consider it that likely that they'd be missing or inaccessible, either.

1 0

Re: Berkeley variant of time zone stuff
by seismo!berkeley.edu!bostic%okeeffe March 29, 1987

March 29, 1987

> It may be, however, that the best way to ream out the environment is > just to do > > extern char **environ; > static char *nullenv = NULL; > > ... > > environ = &nullenv; > > and be done with it. The Berkeley man page for getenv has the comment: Unsetenv removes all occurrences of the string name from the environment. There is no library provision for completely removing the current environment. It is suggested that the following code be used to do so. static char *envinit[1]; extern char **environ; environ = envinit; >> Second, what about the notion of trying for localtime >> (before defaulting to GMT) if the TZ environment variable >> contains something nonsensical? I eventually decided >> against trying for local time; it makes for (very >> marginally) simpler code, and I thought that (for US >> users at least) getting dates reported in GMT would be >> likelier to serve notice that something was wrong with >> the TZ variable. > I agree 100%. The reason I put that code in was because I actually had the code running on a machine that I couldn't put the /etc/zoneinfo directory on. And, for a couple of days, I got a first hand look at what happens when things are 8 hours off. With the current code, it would require a major kernel problem to be more than an hour off. Isn't that worth having? --keith

1 0

Re: Berkeley variant of time zone stuff
by seismo!sun!guy March 29, 1987

March 29, 1987

Is Berkeley's "unsetenv" approach the right one to take to give processes a way of guaranteeing that they run on local wall clock time? Is "tzsetwall" the way to go? Is there some other, better approach? "unsetenv" is the right approach to take to give processes a way of guaranteeing that neither they nor any child processes they spawn will have their behavior affected by the values of environment variables at the time they were run. TZ is one such environment variable, but LOGNAME, USER, and PATH are others. This behavior is necessary for daemon processes that are started as part of a user's session rather than as part of the booting process; e.g., "uucico". It may be, however, that the best way to ream out the environment is just to do extern char **environ; static char *nullenv = NULL; ... environ = &nullenv; and be done with it. On systems where TZ *must* be set for proper operation, you would have to do put it back into the environment after doing this. One possibility here might be to have a function char *defaultzone(void); /* X3J11 syntax; no arguments */ which returns either a pointer to a string indicating the default time zone, or a NULL pointer if not setting TZ will cause the system to use the default time zone. (Admittedly, the latter is a frill; on systems using Arthur's code, for example, it could just as well return a pointer to a string containing "localtime".) A routine would be needed that took a TZ string and used that string to set up the time zone tables. This routine could either be exported (my preference) or kept static. "tzset" would pass the value of the environment variable TZ to this routine; "tzsetwall" would pass the value returned by "defaultzone". A program that wanted to ensure that any children it spawned also used the default time zone would remove TZ from the environment and then call "defaultzone". If the result were non-NULL, it would put that result into the environment as the value of TZ; otherwise, it would just leave TZ out of the environment. First, it would seem to me that having two ways of specifying what local time should be--the /etc/zoneinfo/localtime file, and the results of a gettimeofday system call--is a bad idea. Is there a good reason for keeping the gettimeofday (and settimeofday) system calls? Yes. For one thing, in addition to providing the time zone information, they also provide a higher-resolution system clock. This is useful for determining intervals of real time to higher resolution than one second and, if your machine has a clock that keeps correct time to that resolution, is useful for putting higher-resolution time stamps on events. For another thing, it has to be provided if binary compatibility with old programs is required; they expect the time zone information to be provided by "gettimeofday". It'd be nice to convert those programs, but this isn't always possible or practical. It's unfortunate that this provides another way to get at the time zone information, but that can't really be helped. Note that the "time zone type" part of this information is difficult to use; you'd need to get at the information that currently only appears as hard-coded tables inside "ctime.c", and that doesn't even appear there if you replace the old version of "localtime" with the new stuff. Should the time zone stuff include a replacements for gettimeofday? For settimeofday? No. The time zone stuff does provide a replacement for the time zone part of "{get,set}timeofday". A replacement for the current-time-to-higher-resolution part falls outside of the purview of the time zone stuff; it would be nice if P1003 provided something like this - maybe by providing 4BSD-style "struct timeval"s, or some other high-precision time value, and providing a "getclock" routine that gets that without getting the timezone information ("stime" isn't in P1003, so neither should "setclock"). Should gettimeofday and settimeofday be unceremoniously dropped? They're not in P1003 or the time zone stuff, so there's nothing to drop there. They can't be dropped from systems that provide them, because that would break too many existing programs. Second, what about the notion of trying for localtime (before defaulting to GMT) if the TZ environment variable contains something nonsensical? I eventually decided against trying for local time; it makes for (very marginally) simpler code, and I thought that (for US users at least) getting dates reported in GMT would be likelier to serve notice that something was wrong with the TZ variable. I agree 100%. 3. Berkeley forged ahead and added the "tm_gmtoff" and "tm_zone" elements to the tm structure. 4. Berkeley retained the "solar87" file but in their default distribution it doesn't get compiled (and defines used in localtime and friends are not set up to allow its use); the mod.sources posting does compile the solar87 file (and defines things so that it can be used) unless you take steps otherwise. Is the Berkeley approach best here? Note that the mod.sources posting provides something that you can drop directly into your system if you want, but that you may very well want to modify. As such, I think the mod.sources postings should continue to be set up the way they are; resuppliers of that code (Berkeley, CMU, Sun and other vendors) can set the configuration parameters the way they want. If we end up proposing "tm_gmtoff" and "tm_zone" to P1003 or X3J11, we may want to arrange that they're in by default and that you'd have to take special action to remove them, just to encourage people to provide them.

1 0

Berkeley variant of time zone stuff
by Arthur David Olson March 28, 1987

March 28, 1987

The folks at Berkeley have posted a slight variant of the recent mod.sources time zone posting to comp.bugs.4bsd.ucb-fixes. I'd like to note some of the differences, comment on the differences, and ask for opinions on what to do with Berkeley's changes. 1. Berkeley has dropped the "tzsetwall" function. You call tzsetwall to arrange for "localtime" to deliver the best available approximation to local wall clock time. Berkeley's approach is to provide an "unsetenv" function so that folks can do an unsetenv("TZ") call before calling localtime; since the mod.sources version of the time zone stuff uses local wall clock time if TZ is absent from the environment, this has the desired effect. As Keith Bestic (:-)) notes, this also has the advantage of arranging for forked-off processes to run on local wall clock time. The disadvantage I see here is in porting code to old systems. Take, for example, "sysdate.c", which is designed to print out the system's idea of wall clock time regardless of what the user has set TZ to (potentially useful when calling a system in Paris from Podunk): #include "stdio.h" #include "sys/types.h" extern char * ctime(); main(argc, argv) int argc; char * argv[]; { time_t now; unsetenv("TZ"); tzset(); (void) time(&now); (void) printf("%s", ctime(&now)); return 0; } Now suppose this code lands on a System V Release 2 machine. Our hypothetical code porter tries to compile it and gets an Undefined: _unsetenv diagnostic. The porter then goes ahead and implements unsetenv, and things compile just fine--but when "sysdate" is run, it spits out GMT, which is what System V Release 2 does when TZ is absent from the environment. Is Berkeley's "unsetenv" approach the right one to take to give processes a way of guaranteeing that they run on local wall clock time? Is "tzsetwall" the way to go? Is there some other, better approach? 2. The mod.sources version of "tzset" tries to load up the time zone information specified in the TZ environment variable; if this fails, it sets things up so that GMT is used. The comp.bugs.4bsd.ucb-fixes version: tries to load up the time zone information specified by TZ; if that fails, tries to load up "localtime"; if *that* fails, tries to load up information based on what a "gettimeofday" system call returns; and if *that* fails, loads up GMT. First, it would seem to me that having two ways of specifying what local time should be--the /etc/zoneinfo/localtime file, and the results of a gettimeofday system call--is a bad idea. Is there a good reason for keeping the gettimeofday (and settimeofday) system calls? Should the time zone stuff include a replacements for gettimeofday? For settimeofday? Should gettimeofday and settimeofday be unceremoniously dropped? Second, what about the notion of trying for localtime (before defaulting to GMT) if the TZ environment variable contains something nonsensical? I eventually decided against trying for local time; it makes for (very marginally) simpler code, and I thought that (for US users at least) getting dates reported in GMT would be likelier to serve notice that something was wrong with the TZ variable. 3. Berkeley forged ahead and added the "tm_gmtoff" and "tm_zone" elements to the tm structure. 4. Berkeley retained the "solar87" file but in their default distribution it doesn't get compiled (and defines used in localtime and friends are not set up to allow its use); the mod.sources posting does compile the solar87 file (and defines things so that it can be used) unless you take steps otherwise. Is the Berkeley approach best here? --ado

1 0

Ballot #1 -- results
by seismo!nbires!vianet!devine March 27, 1987

March 27, 1987

Ballot # 1 -- Results # votes ------- 1. Fate of external variables "daylight", "timezone", and "tzname[]" 4 | a. Don't put in standard and discourage use. 2 | b. Don't put in standard and allow implementation-optional use. 2 | c. Place in standard as currently defined in SVID. 2 | d. Place in standard but with different or expanded definitions. OVERALL: Replies for the first round of issues took longer than I anticipated. Also, I am breaking one of my rules: the results will not be piggybacked on a following ballot. I would guess that everyone was looking at the larger picture than just this issue, that is, this issue will fall out of the complete design. The actual count depends on how I read the emphasis of the explanatory text. This ballot might be reissued later when other agreements have been reached. Ballot 2 will be sent out tomorrow night (gotta go home now!) Bob Devine ============================= VOTES ======================================== Bob Devine--------------- Choose 'a'. But I am anticipating how I will vote on "struct tm". The future of the two are intertwined. If can't modify tm, change to d. ------------------------- Arthur Olson------------- Any of the above outcomes are acceptable to me. My favorite with regard to daylight and timezone: a My favorite with regard to tzname: d ------------------------- Chris Torek-------------- b. it should be noted that 4.3BSD does not match SysV, so mandating SVID breaks existing code, and is insufficent ------------------------- dreamit!jjw-------------- My vote > d. Place in standard but with different or expanded definitions. I would like to see a minor extension of the SVID: Make "daylight" an index into "tzname" and allow tzname to be more than 2 elements long. This would allow an easy pickup of the appropriate name and would also allow for those few cases where there are more than one type of daylight savings, e.g "double daylight time". ------------------------- Dennis Mumaugh----------- Vote: d Current definition in SVID is chauvinistic and USA oriented. It assumes that DST is always one hour offset from standard time and that it is advanced. Also one alternate time zone name and one alternate time zone offset. Daylight needs to be changed in meaning, timezone needs to be long timezone[MAXTZ]; offset is derived by timezone[daylight]; and tzname needs to be char *tzname[MAXTZ]; Thus header is #define MAXTZ 10 /* maximum possible changes in Time Rules per year */ time_t timezone[MAXTZ] /* offset from GMT for each Time Rule */ char *tzname[MAXTZ]; /* name of each Rule */ long daylight; /* 0 <= daylight < MAXTZ */ ------------------------- Guy Harris--------------- I vote for a. - Don't put in standard and discourage use. Implementations can provide them if they want, so a. doesn't disallow implementation-optional use. I prefer a. to b. and c. because, as they stand, they may not be able to describe all the wrinkles people can add to their DST rules, and so I'd prefer to discourage them. I prefer a. to d. because 1) I prefer not to use global variables if at all possible and 2) with something like "timelocal" or "mktime", and the Elz-style fields added to "struct tm", it should not be necessary for anybody to need direct access to things like "daylight", "timezone", etc., and the internal data structures used by those routines should be hidden. ------------------------- Mark Horton-------------- Either c or d is OK with me; first choice I guess is c unless a better idea appears. I think it's important to have the conventions for finding out the time zone as part of the standard - I have lots of unportable code because it isn't. ------------------------- Geoff Kuenning----------- I vote (c). If they aren't in the standard, it will break a lot of existing code when manufacturers drop them. I don't like it, but we shouldn't break existing code just because it's ugly. ------------------------- Ron Tolley--------------- I find it difficult to vote on this issue before some other issues have been resolved. Therefore, I will vote conditionally: If the tm structure is changed to provide 1) the difference from GMT in seconds and 2) pointer to a string which contains the time zone name, then vote (a), otherwise vote (c). In either case daylight should not be included in the standard. ------------------------- Shane P. McCarron-------- My response to this question would be b. We have done this with a number of other issues - where the wishes of the committee conflict with reality. I think that this is something that is so in place that we cannot simply write it off. It is interesting to note that the only place I find a reference to timezone in the X3 document is in section 4.12, where it says "The local time zone and Daylight Savings Time are implementation-defined." POSIX has stated (at the December meeting) that we will bow to X3 and X/OPEN for specifics about the timezone stuff. This looks like the answer right here. -------------------------

1 0

Re: Dumb questions about GMT offset in tm structure
by seismo!hplabs!felix!peregrine.peregrine.com!mike March 26, 1987

March 26, 1987

How about having an epoch_t date type which is the number of epochs since a "super-epoch" the advantage of this is that there would be on unique encoding for each date/time. This would aid in both comparison and conversion of times. Any comments?

1 0

Re: Dumb questions about GMT offset in tm structure
by seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt March 24, 1987

March 24, 1987

>Here's a wild idea: >If the two high order bits of a time_t are 11,... At this point, I think we should acknowledge that computers are at as level of sophistication that does not require such an approach to the problem. (However, I would not be opposed some type of Pascal variant record formulation which does the same thing.) Please see my proposal within the last week of defining a parallel date_t signed long integer which would be days (rather than seconds) in the UN*X epoch. (The parallel request is that time_t be signed also.) Using -2147483648 to +2147483647 as the bounds of a 32-bit signed long integer I compute that it would span around 5.8 million years either side of Jan 1, 1970. A date_t and time_t pair of signed long integers could be used together to give a meridian day for any interesting epoch and a time within the epoch. The assumed meridian (for existing applications) would be Jan 1, 1970. > Mark Ron Tolley

1 0

Re: extending the time range
by seismo!sun!guy March 22, 1987

March 22, 1987

I tend to agree with Chris. None of the proposals for changing the type of "time_t" seem to me to stand a chance, given all the old UNIX software out there that has an incompatible notion of what a "time_t" is. Changing "time_t" to something other than an integral type that holds the number of seconds since January 1, 1970, 00:00 GMT would break lots of programs - programs written to obey the rules, not just programs that "cheat" in some way.

1 0

AT&T clock
by seismo!cbpavo.MIS.OH.ATT.COM!mark March 22, 1987

March 22, 1987

I am unaware of any master clock in AT&T used for sync. I do know that it's quite common for the clock in each central office to run at a significantly different rate. The symptom of this is that when you dial 1200 baud from one CO to another, you get a burst of noise on a regular basis - the frequency depends on how close the clocks are. Each time it slips one full tick, there's a phase shift, and with 212 protocol a phase shift turns into a garble. The problem occurs with the newer ESS switches. Mark

1 0

Re: extending the time range
by Chris Torek March 22, 1987

March 22, 1987

All of the proposals I have seen have `RETROFIT' stamped upon them in garish glowing ink. None seem very pretty. Instead of a retrofit, it seems to me one should define a new type, at least 64 bits wide, measured perhaps in microseconds. localtime &c should be renamed, and changed work on these new time values; compability routines would transform old `time_t's to new values, and then return the value returned by the new routines. Chris

1 0

interesting clock sync facts
by seismo!nbires!vianet!devine March 22, 1987

March 22, 1987

To change the topic from the "time_t doesn't work for everything" series of messages here is a note on about synchronizing clocks. And about the limitations of time_t, it is something we can live with. Any extensions should be extensions and not modification to time_t. Too breakable. This has nothing at all to do with Posix, but, I thought that this group might like to hear about it. Ignore if you want. If the wording seems strange at times, bear with it. This was written in a stream of consciousness mode. Note that there are many interesting algorithms described in the OS literature about clock synchronization. Dave Mills has been playing in the real world (TCP/IP connected machines) on how to synchronize clocks. He found that human error accounts for a lot of the problem (as is: "ahhh, was that supposed to be 'AM' or 'PM'?"). ---- Suppose you have N clocks that you would like to synchronize. How would you do it? The answer is "it depends". That is, it depends on how much money you want to spend and how closely synchronized you want the clocks to be. You can see that if you only want to spend one postage stamp, the best you can achieve is +/- several days (the time it takes the mailperson to deliver the letter containing a timestamp). If you cough up some bucks for two modems, you can do better. Etc. What do I mean by synchronization? The best explanation that I've come up with is: consider how the Air Force's precision flying team puts on a show. What matters to them is, first, how tight the formation is, and second, where the planes are with respect to some ground-based marker. Translating that example into clocks shows that clocks can be very close to each other (== synchronized) but still give the incorrect time (!= universal time). Sometimes synchronization is more important than correctness (distributed databases that use timestamps are an example). To get synchronization of clocks AND correctness calls for two things. A mutually agreed upon reference time source supplies the correct time. A convergence algorithm used between clocks supplies the synchronization. Here's a list of time sources that I've heard of: 0. Set clocks at "factory" I include this for completeness. Perhaps the atomic clocks are set this way. I suspect some clocks in satellites are set this way. 1. The electrical "power grid" This is the familiar 60 Hz (or 50 Hz) AC electric line. One could devise a simple counter of the frequency so that all clocks would always be in step with each other. Unfortunately there are several problems. The first is how to initially synchronize the clocks. Also, there are several (5?) different grids in the 48-state area of the US that are not in sync with each other. Plus, each power-grid master clock is only consistent when averaged over the entire day. When peak demands occur, you aren't getting the full 60 Hz per second that you would expect. I've heard that by about 6pm, the grid is lagging by up to 10 seconds. However that lost time is made up while (most) people sleep so that the alarm clock is correct at 8am. [as an aside: leave work early tomorrow and if anyone asks, just give them the above reason :-)] 2. Phone system Each line used by for phone traffic has some timing-dependencies. Major trunk lines have to synchronize. I don't know the details of how the clocks are set. I vaguely remember something about a master clock for AT'n'T located in Indiana (Illinois?) that serves as the reference clock for the entire network. Anyone know more? Problems with this is that the clock is not reachable by users not in the phone company for free (maybe one could lease a T-1 channel and count bits or watch for the 193'rd etc.). 3. Solar based I've read where early clocks were synchronized to noon by someone who watched an instrument's scale for the instant that the sun be at the highest point in the sky. A tiny filament in the instrument served as the focal point for a slit of sunlight, the instrument could only be tilted north and south so that the seasonal tilt was adjusted for. Problems are that it is tedious and labor-intensive. How to set up the solar spotting tube sounds pretty tricky to me. 4. Universal time This is the collection of atomic clocks (over 100 of 'em) around the world that maintain the time. What's good is that is set up, working, and is correct. Problem is dissemination. Unless you are close to an actual clock, there is some delay. However, it is on the order of milliseconds, not too bad. Expenses are getting a receiver for the signal. In the US, there are several frequencies for WWV. Worldwide, one can use a satellite's broadcast if you are lucky enough to be in its "footprint". The GOES satellite serves North America and some of Pan America. I don't know if there is an equivalent satellite for Europe, Africa or Asia. Using a satellite means you have to pop for a dish antenna. 5. Neutron star A spinning neutron star is very periodic. Some are more than others. One neutron star has been watched for over a decade. During that time, it has shown remarkable consistency -- on par with an atomic clock. I'd have to rummage through my notes to get its designation. Problems: besides buying and installing a radio telescope it is very easy... OK, we got a source of time. Now how do we set the clocks? A convergence algorithm can be structured one of two basic ways. The simplest is in a master/multiple-slaves organization. The harder to implement way is in a distributed fashion where each clock shares its "time" with all other clocks. One has to worry about faults (and Byzantine faults, ie, clocks that are "broken" and give different readings depending on who asks it for the time), and compensating for delay in messages between clocks. But the second way leads to some nice advantages for a data network (deadlock detection is easier, can timestamp things for local and remote use, ...) Another problem is related to how clocks move -- forward. Suppose you are going to reset your clock to a new value of time. What happens if that new value is less than the current reading of a clock? Strange things may happen if you set the clock back! Two ways around this are (1) to "stop" the clock until the clock's reading equals the new time and (2) to run the clock slower for a while. On my old pendulum clock at home, I can shorten or lengthen the pendulum if the clock is running slow or fast, respectively. One can't really change the rate of a digital clock. So, one uses the first method. For an OS that updates its clock by seeing interrupts, if the clock is too far ahead some of the updates can be skipped. If the clock is behind, double up some of the clock updates. Careful consideration needs to be done to see if anything (accounting for one!) breaks. Best to do it when no one is using the machine (but then if updates are scheduled for at night and the machine's clock is 12 hours off, strange things will happen). Berkeley's TEMPO time synchronization protocol changed how the clock is set to be better than one second resolution. [If I could find the paper now, I could tell you more. It was in a Usenix proceedings of a couple years ago.] Bob Devine

1 0

RE: Are these limitations...
by seismo!sun!guy March 21, 1987

March 21, 1987

Would the STRUCTURE of the tm structure have to be changed to accommodate the solar time/lunar calendar or the oriental calendaring systems? It depends on whether you want to use "struct tm" to hold calendar dates in other systems or not. It may be possible (e.g. with a scheme like the one used to represent calculations in "terminfo" strings) to write formatting strings that will convert values from a "struct tm" into dates in various Oriental calendars. Are there weekdays in oriental? We may need to indicate the epoch somewhere (for the reign of the Emporer or whatever). >From what I saw on my trip to Japan, it seems that the only difference between Japanese and Western dates/times is that the year is given as years since the year in which the current emperor took the throne, along with the name of his reign. I.e., "now" is (modulo some transposition of fields) Sunday, 22 Mar, Showa 62 (if I remember correctly, last year was Showa 61), 6:08 AM. (Courtesy of "TZ=Japan /usr/src/bin/date" - thanks, Arthur!) Hebrew used the fall of Adam, Is the past tense deliberate here? What calendar is currently used in Israel? However the Oriental calendar uses assension of the emperor. Or "Oriental calendars use". The Japanese calendar does so; what does the current Chinese calendar do? (I think the Soviets changed to the Gregorian calendar after the revolution; what happened post-1945 in China?) That means things change every so often. Yup. This means you can't guarantee that you can convert times in the future correctly. I'm not sure how the Japanese talk about the year 2087; "Showa 162" would sound a bit presumptuous to me. They may just punt and use the Gregorian calendar here.

1 0

Re: Dumb questions about GMT offset in tm structure
by seismo!cbpavo.MIS.OH.ATT.COM!mark March 21, 1987

March 21, 1987

> 2) Provide a general-purpose time value manipulation package > for the benefit of applications that have to deal with > arbitrary dates and times. > > In fact, you may even be able to write the latter package in some > language available on lots of machines (C, Fortran, whatever), and > decouple it from the system entirely. Unfortunately, such a library has to know all the time zone rules, which means it has to redo all the stuff ctime does. It also has to know the local conventions for figuring out what time zone you're in, which means it won't be portable. The bulk of this package would be very similar to ctime.c or ADO's package. I would prefer to see either an upward compatible extension or else a dual interface to the same code. Mark

1 0

Re: Dumb questions about GMT offset in tm structure
by seismo!cbpavo.MIS.OH.ATT.COM!mark March 21, 1987

March 21, 1987

Here's a wild idea: If the two high order bits of a time_t are 11, the rest of the bits are taken as a number of days since some early epoch, perhaps 1858 or something in that general ballpark. (1900 isn't quite early enough for our application.) Actually, a quick calculation shows that this allows for nearly 3 million years, so we could easily adopt the year 0 AD as the epoch. The disadvantage to this is that time_t is no longer a simple arithmetic type, although any application that knows it's dealing with timestamps can still assume it is. Only the canned routines like ctime need to know about it. Another disadvantage is that time_t used as a timestamp now only extends to about 2071. By using more than 2 bits as a flag, this could be extended. For example, if the flag were that all 8 high bits are 11111111, it covers 46,000 years, still plenty. It could even be a signed quantity, allowing years from 23,000 BC to 23,000 AD. This only loses 194 days from the end of the range in 2106. Mark

1 0

Re: Dumb questions about GMT offset in tm structure
by seismo!sun!guy March 20, 1987

March 20, 1987

Given that some people want a facility in some system library to manipulate dates prior to 1902, why not: 1) Leave the UNIX time manipulation routines alone, and use them only for what they were intended - dealing with time stamps for system events. 2) Provide a general-purpose time value manipulation package for the benefit of applications that have to deal with arbitrary dates and times. In fact, you may even be able to write the latter package in some language available on lots of machines (C, Fortran, whatever), and decouple it from the system entirely.

1 0

Re: Dumb questions about GMT offset in tm structure
by seismo!nbires!vianet!devine March 19, 1987

March 19, 1987

Someone wrote: > Yes, but nothing in a UNIX system happened in the 19th century. > Non-UNIX systems lacking "time_t" have done quite well dealing with > times; I don't see any need to use "time_t" for every kind of > timestamp any application could possibly want. Mark replied: ! Sorry, but I disagree. UNIX provides some very nice date/time ! manipulation routines, [...]. I had to reinvent this wheel, and ! I swiped code from ctime like crazy. I wound up choosing ISO time ! (char string) as my standard format. While Unix does not need dates before 1970, I agree it should be more flexible. In order to provide a consistent time format for a network of heterogeneous machines that had time epochs != 1/1/70, I too used the ISO format for dates and times. I didn't have to go as far as Mark did because only network programs (that cared) used the new date/time format; existing programs used OS-dependent calls. Pre-epoch dates were a pain... Bob Devine

1 0

Re: Dumb questions about GMT offset in tm structure
by seismo!cbpavo.MIS.OH.ATT.COM!mark March 18, 1987

March 18, 1987

> > Sometimes we care about things that happened in the 19th century > > (birthdates, for example.) > > Yes, but nothing in a UNIX system happened in the 19th century. > Non-UNIX systems lacking "time_t" have done quite well dealing with > times; I don't see any need to use "time_t" for every kind of > timestamp any application could possibly want. Sorry, but I disagree. UNIX provides some very nice date/time manipulation routines, which know about time zones and daylight time, months of the year, leap years, and various other ugly stuff that people don't like to reimplement. An application that has to store a date has a strong incentive to use the existing routines rather than to invent a new format. It would be VERY NICE if the UNIX routines were useful for more than just timestamps on the local system. It is not necessary that time_t be used for this, as long as there is some standard representation that can do it. ctime might be one, ISO time might be one, or struct tm might be one, or it might be something new. I had to reinvent this wheel, and I swiped code from ctime like crazy. I wound up choosing ISO time (char string) as my standard format. My resulting code is highly unportable, because it knows about time_t and two different conventions for time zone, and it has all the daylight rules built into it. Mark

1 0

Re: List of issues
by ado March 18, 1987

March 18, 1987

> > Should time() return an implementation defined time > > representation or should it return elapsed seconds > > since midnight January 1 1970 GMT? > The current POSIX draft already states that it returns the latter; do > we want to change this? No. . .I want to make sure it stays that way. > X3J11 also has "time" and "time_t", although since they're not > defining an OS standard they do not require "time_t" to be an > integral type representing seconds since the epoch. Ideally, I'd like to see both X3J11 and POSIX define time_t as elapsed seconds since midnight January 1 1970 GMT, and see them both define the time function as returning such a value. If this isn't possible, I'd like to see X3J11 define *differently-named* types and functions--tempus_t and tempus, or whatever. My fear is that there are programs out there that "know" what a time_t is that "know" what the "time" function returns, and that will break if things are changed. -- UUCP: ..seismo!elsie!ado ARPA: elsie!ado(a)seismo.ARPA Elsie and Ado are trademarks of Borden, Inc. and Ampex.

1 0

Ballot # 1
by seismo!nbires!vianet!devine March 18, 1987

March 18, 1987

Since this is the first ballot, here are the balloting rules: 1. Send votes by mail to me (uucp address below) 2. If you feel that the offered choices for an issue are not sufficient, send me mail with suggested addition. If enough suggestions (or one whose argument is compelling) a new round of voting on that issue will be done. 3. Vote EARLY and only once (even if you are from Chicago). 4. If a message never got to your mailbox (you can tell by the reception of the next higher ballot) I will send another to you if it might make a difference in the total vote. 5. Results are piggybacked on ballots to reduce the number of messages. 6. Because there are X issues and not X weeks to discuss them, there will be several ballots per week. 7. I will not decide "winning" choices. I will only keep a count. 8. Discussion of each ballot in the mailing list is encouraged. 9. NOTE: Your votes are not the final say on how the Posix document is structured but are intended to provide valuable input. >> How best to forward the results is still unknown -- comments please.<< If you have any issues you want to see included, please send them to me. I am starting out with, what I hope, will be an issue that will not cause too much argument and gnashing of teeth. Bob Devine {nbires, hao, ihnp4!stcvax} !vianet!devine ----------------- This is Ballot # 1 on Posix time-related issues. 1. Fate of external variables "daylight", "timezone", and "tzname[]" a. Don't put in standard and discourage use. b. Don't put in standard and allow implementation-optional use. c. Place in standard as currently defined in SVID. d. Place in standard but with different or expanded definitions. ----------------- CURRENT LIST OF ISSUES 1. Fate of the external variables daylight, timezone, and tzname[] [ undecided ] 2. Use the user's environment variable to define the timezone for that user [ undecided ] 3. Use the user's environment variable to define timezone rules [ undecided ] 4. How user selects a non-default timezone [ undecided ] 5. Allow user to define a new timezone and set of rules [ undecided ] 6. Definition of what struct tm (or struct new_tm) contains. [ undecided ] 7. List of what time functions are needed. [ undecided ] 8. Definition of what time_t holds.-- implementation defined or seconds since some epoch (eg, 1/1/1970). [ undecided ] 9. Drop mktime from standard because of lack of existing art? [ undecided ]

1 0

Re: Dumb questions about GMT offset in tm structure
by seismo!sun!guy March 18, 1987

March 18, 1987

Sometimes we need subsecond precision. Yes, but "time_t"s need not provide subsecond precision; 4.[23]BSD-style "struct timeval" may not be ideal, but they do the job. Sometimes we care about things that happened in the 19th century (birthdates, for example.) Yes, but nothing in a UNIX system happened in the 19th century. Non-UNIX systems lacking "time_t" have done quite well dealing with times; I don't see any need to use "time_t" for every kind of timestamp any application could possibly want. It might be aesthetically "nice" to have the time representation used by the OS be the same that would be used by every conceivable application, but I don't see that it's worth the effort of changing what a "time_t" is. (There are plenty of OSes out there with the same problem; the VMS epoch starts 00:00 - local time, I believe - November 17, 1858.)

1 0

Re: List of issues
by seismo!sun!guy March 18, 1987

March 18, 1987

1. Should time() return an implementation defined time representation or should it return elapsed seconds since midnight January 1 1970 GMT? The current POSIX draft already states that it returns the latter; do we want to change this? If it does not return elapsed seconds, should the name "time" (or the type name "time_t") be changed (so as to noisily break existing code, rather than quietly breaking existing code?) X3J11 also has "time" and "time_t", although since they're not defining an OS standard they do not require "time_t" to be an integral type representing seconds since the epoch.

1 0

Re: northamerica timezones & Saskatchewan
by seismo!nbires!vianet!devine March 17, 1987

March 17, 1987

Darwyn Peachey peachey(a)sask.UUCP writes: > If I am reading your "northamerica" (version 3.1) timezone file correctly, > it appears to be inaccurate concerning the province of Saskatchewan in > Canada. You seem to assume that all of Canada observes the DST rules. > In fact, Saskatchewan is always on standard time and has been for several > years (up to 20, I'd guess). To be more precise, we are always on daylight > time, since we are geographically in the Mountain zone, but we use Central > Standard Time year round! The information I have found on Saskatchewan Daylight Time is this: 1962-1971 Variable (each locality may have done something different) but it seems to be last Sunday in April to last Sunday in October (September in 1960-1) 1972-present? Observed in entire province except in the far-eastern part (that part is on Central Standard time all year) The western part is on the last Sunday in April to last Sunday in October schedule I don't know where the machine 'skorpio' is but I infer that it is in the Eastern part of Saskatchewan. Does anyone have access to an official publication of Canada that describes DST? Does such a publication exist? Bob Devine

1 0

Re: northamerica timezones & Saskatchewan
by Arthur David Olson March 16, 1987

March 16, 1987

> Saskatchewan is. . .always on daylight time, since we are geographically > in the Mountain zone, but we use Central Standard Time year round! > Thus, there is always a four hour time difference between us and Hawaii. . . > Darwyn Peachey peachey(a)sask.UUCP peacheyd(a)sask.BITNET (306) 966-4909 With a machine name like sask, I'll willing to accept your word as authoritative! Is "CST" the right time zone abbreviation to use in your neck of the woods? Is this: Zone Canada/Saskatchewan -6:00 - CST the right line to have in the northamerica file? --ado

1 0