- tz - lists.iana.org

Re: Berkeley variant of time zone stuff
by seismo!vianet!devine April 2, 1987

April 2, 1987

I just finished reading Keith Bostic's posted patches for 4.[23] time functions. I disagree with the way that a compiled-in table is still used if the TZ env variable is not defined. Such tables should be extirpated. Note that the new 1987 version of when Daylight Saving Time starts **is not a national law**. Each state can decide to use the first or last Sunday in April to start DST. Each state may decide to even have DST. One lesson the should be learned is that DST rules are extremely changeable. The future holds more possible changes: presidential years may have timezone-dependent DST; Colorado may decide to use year-'round DST (the bill was just introduced last week). Will Berkeley issue a new series of code patches every time a change occurs? Bob Devine

1 0

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

April 2, 1987

> Point taken; clearly the gettimeofday system call must be retained > (which implies that settimeofday has to hang around too) > to help out old binaries. More importantly, it has to be retained for better than second resolution. > Or "/etc/TIMEZONE". S5R3.1 currently has "init" load up the > environment from what's in "/etc/TIMEZONE". Presumably, you could > have "defaultzone" read the setting of TZ from this... > > or generate a string from the abbreviations and other > information stored in the "/etc/zoneinfo/localtime" file. > > or generate that string. > > But there doesn't seem to be any way to get > unsetenv("TZ") > (the Berkeley posting approach) to give the desired effect of > getting your process--and any children that it later forks > off--running on local wall clock time. If you take that approach > on a System V system, and then fork off an "old" binary, the old > binary will end up using GMT. > I'm sorry, but I'm not following this whole discussion. It seems to me that S5 has the problem here; BSD offers two different ways to guarantee that "localtime" is used, setenv("localtime") and unsetenv("TZ"). S5 has no way (does it?) to do so. Adding another way to BSD won't help the situation. Now, if S5 wanted to add something, I could understand wanting to add it to BSD. > That's why I suggested the "defaultzone" routine - you need some > portable way of setting the TZ environment variable; given existing > systems, removing it isn't a portable way of forcing local wall clock > time. To make this portable, you'll have to alter S5, right? --keith

1 0

Re: Addition to Arthur Olsen/4.3bsd table-driven ctime
by Arthur David Olson April 1, 1987

April 1, 1987

> 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 Even %4d won't guarantee the advertised 26-character length if tm_year is big (or small) enough (for example, 10000); bogus tm_wday and tm_mon values can cause problems as well. You may want to send a note to an X3J11 committee member. offtime was declared static in the mod.sources posting unless STD_INSPIRED was defined. Its eventual fate lies more in the hands of standards committees and other folks wiser than yours truly at this point. --ado

1 0

Re: Berkeley variant of time zone stuff
by Arthur David Olson April 1, 1987

April 1, 1987

First a new question, then stuff inspired by old communicaitons. The new: System V systems run on GMT if there's no TZ environment variable. The new time zone stuff arranges to run on whatever's described in the file "/etc/zoneinfo/localtime" if there's no TZ environment variable. Now you *can* force compatibility either by describing GMT in the file "/etc/zoneinfo/localtime" or by not having the file at all (although this plays hell with the localtime(3) claim that you're getting the "best available approximation to local wall clock time). But would it be a better idea--for the sake of compatibility with System V--for the new time zone stuff to use GMT if there's no TZ environment variable? ---------- ado > > Is there a good reason for keeping the gettimeofday (and ado > > settimeofday) system calls? guy > . . .it has to be provided if binary compatibility with guy > old programs is required; they expect the time zone information to be guy > provided by "gettimeofday". It'd be nice to convert those programs, guy > but this isn't always possible or practical. Point taken; clearly the gettimeofday system call must be retained (which implies that settimeofday has to hang around too) to help out old binaries. A slightly ugly possibility is to conditionalize "/usr/include/sys/time.h": struct timezone { #ifdef KERNEL int tz_minuteswest; int tz_dsttime; #else /* !KERNEL */ int :32; int :32; #endif /* !KERNEL */ }; to preclude use of tz_minuteswest and tz_dsttime when a program is recompiled. This is perhaps more encouragement to convert than is appropriate. :-) One advantage, though, is that the change is invisible to gettimeofday callers who are only interested in getting higher precision time. A find /usr/src -name "*.c" -exec grep -l tz_ {} \; is on my list of things to do. ---------- Guy's reminder about supporting old programs also got me thinking about one of Guy's asides: > On systems where TZ *must* be set for proper operation, you would > have to do put it back into the environment. . .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".) Setting TZ to "localtime" would work fine on a BSD system--"new" programs would be using the new time zone stuff and would honor it; "old" programs would be calling gettimeofday. But if it's a System V system with "old" binaries, "localtime" probably isn't what you want to put in the environment, since doing that would convince such child processes that you wanted to run on GMT with the time zone abbreviation "loc". There are a couple of ways to get around this--set up a "/etc/zoneinfo/defaultzone" file that contains the value to return, or generate a string from the abbreviations and other information stored in the "/etc/zoneinfo/localtime" file. But there doesn't seem to be any way to get unsetenv("TZ") (the Berkeley posting approach) to give the desired effect of getting your process--and any children that it later forks off--running on local wall clock time. If you take that approach on a System V system, and then fork off an "old" binary, the old binary will end up using GMT. I think the simple way out here just to avoid promising a way of getting your process and its unborn children running on local time. I still *do* want to provide a way to get your process--though not necessarily its unborn children-- running on local time; either unsetenv("TZ") or tzsetwall() does this job. The wise words from California are that unsetenv("TZ") is the way to go; are there any other words? --ado

1 0

Re: AT&T clock (synchronization)
by seismo!nbires!vianet!devine April 1, 1987

April 1, 1987

Mark writes: > 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. I just got a reply back from a friend who works for AT&T in Denver. He says: > I'm not too sure about how central offices are set up for clock timing. > My past work in AT&T was with the long-distance calling switches (toll > offices). Back when AT&T was a monopoly, all the toll switching centers > kept their internal clocks in sync via a high-precision clock located > somewhere in Missouri. Presumably (but I'm not sure), the toll centers > passed along clock sync information to any connected tandem or local > central offices. With the breakup, all of this stuff must have been changed > dramatically. Bob Devine

1 0

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

northamerica timezones & Saskatchewan
by seismo!ihnp4!skorpio!peachey March 16, 1987

March 16, 1987

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! Thus, there is always a four hour time difference between us and Hawaii (whereas the temperature difference varies from -130F to +20F). Darwyn Peachey peachey(a)sask.UUCP peacheyd(a)sask.BITNET (306) 966-4909

1 0

Re: Dumb questions about GMT offset in tm structure
by Arthur David Olson March 15, 1987

March 15, 1987

> > Dumb question #2: if there's a way to turn tm structures ... > > does .. [ being able to deduce it ] ... > > obviate the need for a GMT offset element in the tm structure? > Certainly, this is possible. . .But the zone offset information is trivially > available to localtime, it seems like it can't hurt to provide this extra > information, essentially for free. The only place I can think of that it might hurt is if someone has squirreled away tm structures in a disk file. If that's happened, the committee's desire to avoid breaking existing code would argue against changing the tm structure. Now if you change the structure's name, then code will break noisily-- something the committee seems willing to accept. -- UUCP: ..seismo!elsie!ado ARPA: elsie!ado(a)seismo.ARPA Elsie and Ado are trademarks of Borden, Inc. and Ampex.

1 0

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

March 15, 1987

Dumb question #1: what applications use the offset from GMT of local time? (That is, why do we want the offset in the tm structure in the first place?) I've run across it in networking applications, such as mail, netnews, and transactions. They get char string date/time info from some other place (possibly around the world) and have to understand it. Dumb question #2: if there's a way to turn tm structures into time_t values, does the ability to do something like offset = time_of_interest - convert_tm_to_gmt(localtime(time_of_interest)); (possibly followed by offset = -offset; depending on what sex you think the offset should be) obviate the need for a GMT offset element in the tm structure? Partly. At the higher levels, what I really want to do is things like this: Convert gmtime char string to localtime char string Convert localtime char string to gmtime char string Compare two times to see which is older. Compare two times to see if one is more than X older or newer than the other Add or subtract X hours (minutes, days, seconds, years) from a time. Also, a long isn't enough to handle the times of interest. Sometimes we need subsecond precision. Sometimes we care about things that happened in the 19th century (birthdates, for example.) Part of me wonders if a floating type could be used for time_t. Nobody wants subsecond precision on a birthdate, although they might want it for times very close to "now". I guess what I really want is a floating point where zero means "now", but that doesn't exactly work out unless you throw in a fixed reference point. Mark

1 0

Re: Dumb questions about GMT offset in tm structure
by Robert Elz March 14, 1987

March 14, 1987

Date: Sat, 14 Mar 87 13:29:55 EST From: elsie!ado (Arthur David Olson) Message-ID: <8703141829.AA01740(a)elsie.UUCP> Dumb question #1: what applications use the offset from GMT of local time? Anything which wants to record time in local time (for ease of human reading) but be precise about the zone so the precise GMT time can be reconstructed. Mailers are a prime example, the Date: line should contain such an offset (only in the 5 US zones is it allowable to use an abbreviation .. except the stupid US military one letter abbreviations; and even those 5 are only allowed in rfc822 style mail, ISO stuff always requires the numeric offset) Dumb question #2: if there's a way to turn tm structures ... does .. [ being able to deduce it ] ... obviate the need for a GMT offset element in the tm structure? Certainly, this is possible. Initially I wasn't realy impressed with the need for the offset in the struct tm because of how easy it is to obtain this way (even without the inverse functions, its not hard to do a struct subtraction (ie: multiple subtractions, with additions & multiplications to combine the answers) of the results of gmtime() and localtime()). But the zone offset information is trivially available to localtime, it seems like it can't hurt to provide this extra information, essentially for free. kre

1 0

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

March 14, 1987

Dumb question #1: what applications use the offset from GMT of local time? (That is, why do we want the offset in the tm structure in the first place?) I've run across it in networking applications, such as mail, netnews, and transactions. They get char string date/time info from some other place (possibly around the world) and have to understand it. Dumb question #2: if there's a way to turn tm structures into time_t values, does the ability to do something like offset = time_of_interest - convert_tm_to_gmt(localtime(time_of_interest)); (possibly followed by offset = -offset; depending on what sex you think the offset should be) obviate the need for a GMT offset element in the tm structure? Partly. At the higher levels, what I really want to do is things like this: Convert gmtime char string to localtime char string Convert localtime char string to gmtime char string Compare two times to see which is older. Compare two times to see if one is more than X older or newer than the other Add or subtract X hours (minutes, days, seconds, years) from a time. Also, a long isn't enough to handle the times of interest. Sometimes we need subsecond precision. Sometimes we care about things that happened in the 19th century (birthdates, for example.) Part of me wonders if a floating type could be used for time_t. Nobody wants subsecond precision on a birthdate, although they might want it for times very close to "now". I guess what I really want is a floating point where zero means "now", but that doesn't exactly work out unless you throw in a fixed reference point. Mark

1 0

Are these limitations in the mod.sources time zone stuff worth worry?
by Arthur David Olson March 14, 1987

March 14, 1987

Completely off the standardization track for a moment. . . There are some limitations in the time zone stuff that was recently posted to mod.sources; I'm wondering if other folks have opinions on whether the limitations are worth worrying about, or if folks have inspired changes to the code that will get around the limitations. If you're not the nit-picking type, please feel free to ignore this letter. A preamble: the format of the files stored in the /etc/zoneinfo directory was designed to keep the files small and thus to keep down the overhead involved in reading the time zone information from disk. For example, here on Elsie, the "/etc/zoneinfo/US/Eastern" file weighs in at 814 bytes, which means that the time zone information fits in one logical disk block. And now. . . 1. While the file format allows big-endian and little-endian machines to use the same (file-server-provided) file to get time zone information from, it can't be used both by (traditional) machines that want to have signed time_t's and by (kre-controlled Australian) machines that want to have unsigned time_t's. Is this worth worrying about? Should the transition times be stored as "long long"s, doubles, or text? Does the added utility warrant the extra storage? 2. There are all those nasty "MAX"es built in to tzfile.h (and, by reference, into localtime et al.): #define TZ_MAX_TIMES 370 /* Maximum number of transition times */ #define TZ_MAX_TYPES 10 /* Maximum number of local time types */ #define TZ_MAX_CHARS 50 /* Maximum number of abbreviation characters */ Are the limits worth worrying about? Should localtime et al. do memory allocation to overcome the limits? Should the functions buffer some of the time zone informtion and go to disk if information that's needed isn't in the buffer? 3. And then there's Saudi Arabia. (I trust folks saw the recent Scientific American article on newly available digital watches that, when fed longitude and latitude, will provide local solar time-- this allows Moslems to observe daily prayers.) To do Saudi Arabia right--or at any rate, to do it right to the second--you need about 2000 local time types. Since, these days, local time types are stored on disk as unsigned chars, you can only get 256. The easy way out would be to encode time types the same way that transition times are encoded; this would about double the size of time zone information files. Is the added functionality worth the size doubling? Is the problem even worth worrying about? Is there a better way to deal with it? -- UUCP: ..seismo!elsie!ado ARPA: elsie!ado(a)seismo.ARPA Elsie and Ado are trademarks of Borden, Inc. and Ampex.

1 0

Dumb questions about GMT offset in tm structure
by Arthur David Olson March 14, 1987

March 14, 1987

Dumb question #1: what applications use the offset from GMT of local time? (That is, why do we want the offset in the tm structure in the first place?) Dumb question #2: if there's a way to turn tm structures into time_t values, does the ability to do something like offset = time_of_interest - convert_tm_to_gmt(localtime(time_of_interest)); (possibly followed by offset = -offset; depending on what sex you think the offset should be) obviate the need for a GMT offset element in the tm structure? -- UUCP: ..seismo!elsie!ado ARPA: elsie!ado(a)seismo.ARPA Elsie and Ado are trademarks of Borden, Inc. and Ampex.

1 0

Re: List of issues
by Arthur David Olson March 14, 1987

March 14, 1987

A few more issues: 1. Should time() return an implementation defined time representation or should it return elapsed seconds since midnight January 1 1970 GMT? 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?) Should the names of other functions that deal with time_t values be changed? 2. If elements are added to the tm structure, should it be renamed? 3. Even if elements aren't added to the tm structure, should it be renamed? (As Guy Harris has pointed out, the standard does not define the order in which the structure's elements appear and does not preclude adding structure elements. So the "new" tm structure might be different on different machines, whereas "old" tm structures where the same on different machines. This represents a change in the tm structure's nature, and so may warrant a change of name to avoid quietly breaking existing code.) 4. Drop mktime from standard because of lack of existing art? -- UUCP: ..seismo!elsie!ado ARPA: elsie!ado(a)seismo.ARPA Elsie and Ado are trademarks of Borden, Inc. and Ampex.

1 0

List of issues
by seismo!nbires!vianet!devine March 14, 1987

March 14, 1987

Here is a list of issues that should be settled. I used Ron Tolley's message as the source. PLEASE send me any issues that you feel should be incorporated into the list. 1. Extend tm structure to contain timezone name 2. Extend tm structure to contain local timezone offset from UT 3. Extend tm structure to contain local seasonal time offset from UT 4. Eliminate the external variables daylight, timezone, and tzname[] 5. Eliminate the tzset() function. 6. Use the user's environment variable to define the timezone for that user 7. Use the user's environment variable to define timezone rules 8. Allow user to select a non-default timezone 9. Allow user to define a new timezone and set of rules Starting next week (Mon = 3/16/87), I will send out a "ballot" on a single issue. Send me your vote (I will ACK your vote when it is received), and I will tally the results. When discussion on an issue seems to have stopped, I will send out the total. Does anyone have a suggestion for how best to communicate the results to the Posix general group? Guy (because you attend the meetings), would you like to present them? Likewise, does anyone have the ear of the X3J11 committe? Bob Devine

1 0

Re: List structure and standards making
by seismo!sun!guy March 14, 1987

March 14, 1987

People will be relieved in that, except for the casting (sic) into concrete of struct tm, Given that the draft does not say "'struct tm' looks like this", but just says that "the structure shall contain at least the following members", it is incorrect to say that that the structure has been cast into concrete. An OS that supports an X3J11-compliant C implementation is perfectly free to add new members to "struct tm". As it stands now, we plan to add Elz' new members, with his names for them, in a future release. Thus the current discussions on the whole time subject are rapidly becomming academic... People will be relieved in that, except for the casting (sic) into concrete of struct tm, much is left unsaid, especially things like timezones; Given that much is left unsaid, some discussions of timezone are most definitely *not* academic, and X3J11 will not render them so; various OSes that support X3J11-compliant C implementations can and will do different things here. POSIX systems will have to do something; the proposal already made to P1003 is a good start, at least.

1 0

Re: List structure and standards making
by seismo!munnari!basser.oz!john March 13, 1987

March 13, 1987

> Thus the current discussions on the whole time subject are > rapidly becomming academic Dennis, The discussions are certainly NOT becoming academic. There are a lot of people who just don't care what X3J11 says; who believe that X3J11 is irreparably broken, and intend to ignore it into the indefinite future. It may well be that ``the ANSI C is already spoken.'' For my money, the ANSI C is already buggered. Now this is not to say everyone feels like this. I am sure that people from various manufacturers feel the standard is important. But real (K&R) C is going to be around for a long time. Don't assume it will automagically become extinct with the release of X3J11. John ``Down With ANSI C'' Mackin, Basser Department of Computer Science, University of Sydney, Sydney, Australia john(a)basser.oz.AU (john%basser.oz(a)SEISMO.CSS.GOV) {seismo,hplabs,mcvax,ukc,nttlab}!munnari!basser.oz!john Thought for the century: The worst crime a standards-maker can commit is innovation.

1 0

Re: TZ list structure
by seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt March 10, 1987

March 10, 1987

Bob, Please go ahead. I agree that we have bantered around long enough. The summary which I mailed our recently could serve as a preliminary list of issues. I am sure that others should be added. Ron Tolley

1 0

List structure and standards making
by seismo!cuuxb!dlm March 10, 1987

March 10, 1987

While the list has been discussing time and timezones in context of the IEEE P1003 standards committee, people have lost sight of X3J11 which is much more important and further along towards casting into concrete. (Dramatic effect) As we now talk, the concrete has been laid and is hardening. (End drama). People should get out their X3J11 Draft Proposed American Standard for Information Systems -- Programming Language C (Dated October 1, 1986). This standard is ALREADY entering the balloting process. Please turn to page 151 and following: Section 4.12 -- Date and Time. The standard ALREADY covers clock_t, time_t, struct tm (without new strings or fields!!), clock(), time(), difftime(), mktime(), asctime(), ctime(), gmtime(), localtime(), strftime(). Thus the current discussions on the whole time subject are rapidly becomming academic as the ANSI C is already spoken and the C standard is currently in the comment phase -- send a comment and proposed change of ruling. The next phase is balloting and trial use. People will be relieved in that, except for the casting (sic) into concrete of struct tm, much is left unsaid, especially things like timezones; except to say if timezone is unknown or unsupported return (int)-1 in the approporiate place, and for gmtime return NULL if the offset is unknown. Also checkout the semantics of mktime!! -- =Dennis L. Mumaugh Lisle, IL ...!{ihnp4,cbosgd,lll-crg}!cuuxb!dlm

1 0

TZ list structure
by seismo!nbires!vianet!devine March 10, 1987

March 10, 1987

This missive argues for a different purpose of this mailing list. Currently it is used for presenting different proposals for how to deal with timezones, and seasonal time changes for Posix. Many times what happens is that arguments are sent out into the list on a certain point of view but no lasting effect is seen. I urge that this list be used to form a consensus on the issues and solutions. The mailing list members would then speak with one voice to the 1003 committee instead of several voices that only give disharmony. All issues seem to have been raised (one or twice or...). What would remain for us to do is to agree on how to do things. Too often messages have been sent but permanent resolve was obtained. I am willing to be the sender of the ballots and counter of votes. Note that the Posix group would have another shot at changing things and that the 1003 balloters would have final say. Each ballot would be organized in a "single issue; multiple choice for resolution" format. Example: Proposition H. The structure tm should be changed so that the current timezone is added by: 1. should add a 'char *' entry for the name 2. should add a constant sized arrary for name 3. should have an index into a standard file 4. should have an interactive prompt for the TZ name (only kidding...) 5. should not add the name Bob Devine

1 0

DST in Saskatchewan, Canada
by Justin Bur March 6, 1987

March 6, 1987

The province of Saskatchewan, normally in the Central time zone, has not used daylight savings time for the past several years. I think there was some talk of using it for the first time this year, but I don't remember. I also don't know if DST has never been used in Sask. or if it used to be used some time ago: my source is the national radio schedules of the Canadian Broadcasting Corporation, and my subscription started in 198?. I will send more precise information if I can find it, but it would probably be best to find a local source of information. I *think* sask.uucp is the University of Saskatchewan; I don't have a uucp map handy. Justin Bur -- Universite de Montreal <burj(a)iros1.uucp> seismo!think!mosart!mcgill-vision!iros1!burj

1 0

mod.sources posting; mktime
by Arthur David Olson Feb. 22, 1987

Feb. 22, 1987

I've passed on new time zone stuff to some other folks on the list; after their editing, the stuff should be posted to mod.sources. It will (in all probability) include "food for thought" code for six (count 'em, six) functions for turning time_t's into struct tm's and back: struct tm * localtime(time_t t) struct tm * gmtime(time_t t) struct tm * offtime(time_t t, long offset) time_t timelocal(struct tm * tmp) time_t timegm(struct tm * tmp) time_t timeoff(struct tm * tmp, long offset) localtime and gmtime are our old friends. offtime is like gmtime except that the given offset (in seconds) is used in generating the return value. (You want to do this, rather than adding the offset to the time and calling gmtime, to avoid overflow problems at near-minimum and near-maximum time_t values.) timelocal, timegm, and timeoff "invert" their counterparts (well, actually, they just try to do an adequate job). The troff-ish assumption with localtime and timelocal is that "the same local time conversion rules must still (or again) be in effect" when timelocal is called as were in effect when localtime was called to get the "right" inversion. None of the inverting functions gives a hoot about tm_isdst. There's surely a better way to do things. --ado

1 0

Re: When to use DST rules
by seismo!nbires!vianet!devine Feb. 21, 1987

Feb. 21, 1987

dreamit!jjw suggests: 1. [more than a year or two of DST rules is overkill] 2. "Since the DST rules are subject to the whims of politicians and bureaucrats, any rules beyond the next year are as likely to be wrong as right." 3. "a file containing several years of DST Rules can be expensive to search and a program to calculate DST for multiple years is unnecessarily complex." I agree that providing all rules of all years is overkill for most users. But who can say beforehand which rules are needed by a particular site. Consider how termcap/terminfo entries are provided: All possible terminal descriptions are distributed but a user can remove any unneeded descriptions. It is not correct that DST rules are completely unfathonable. Yes, they do change and one can only guess what the DST rules will be in far distant years. This only means that changing the DST database should be quicker and easier to do than for the "politicians and bureaucrats" to pass laws. So, the rule should be to provide an implementation with sufficient flexibility so that a user can use it with all rules or just those that are wanted. Don't decide for someone. Bob Devine

1 0

minutes east or minutes west
by Chris Torek Feb. 21, 1987

Feb. 21, 1987

Just a side point... pick one or the other for `struct tm', then stay with it. We can change all the old code now and conform to ISO, or we can buck the tide as long as we want. Having one field one way and another the other, however, is a mistake: That way lies madness.

1 0

(1) minutes east/west and (2) aust time
by Snoopy Feb. 21, 1987

Feb. 21, 1987

I've been watching the discussion on minuteswest vs minuteseast, and there's a point that I haven't seen brought up yet. The math is a bit less confusing if you use minuteseast. I modified date(1) to allow setting the timezone to any number of minutes west of GMT you want. It was a bit confusing typing "date -z 2:15" and having date print out something like "Fri Feb 20 20:00:00 GMT-2:15 1987". (Notice the sign change!) Turns out that if you take the time in GMT and add minutesEAST, you get the correct time for your zone. west GMT east wall clock time 10:00 11:00 12:00 1:00 2:00 minuteswest/60 2 1 0 -1 -2 minuteseast/60 -2 -1 0 1 2 Other than the pain of converting existing software, it appears that minuteseast is a better choice. ----------------- Also, does anyone know the correct timezone names for Australia? The following is from 4.3 timezone.c: -10*60, "EST", "EST", /* Aust: Eastern */ -10*60+30, "CST", "CST", /* Aust: Central */ -8*60, "WST", 0, /* Aust: Western */ It seems a bit odd to be that there is no indication of daylight time (e.g. EDT, CDT) except for the western zone, which gives "GMT+8:00" during their summer. I find it hard to believe that the Australians refer to their timezone as "GMT+8:00". Snoopy tektronix!doghouse.gwd!snoopy snoopy(a)doghouse.gwd.tek.com

2 1

Re: When to use DST rules
by seismo!sun!guy Feb. 20, 1987

Feb. 20, 1987

This seems like overkill. Sigh. We've been through this before. Existing UNIX systems do this, and as such people may expect it. Unless I see good *hard* evidence that nobody has done this and that nobody will do it, I see no reason to go through the effort of removing this capability from the code. Since the DST rules are subject to the whims of politicians and bureaucrats, any rules beyond the next year are as likely to be wrong as right. No, they're probably more likely to be right than wrong, in most cases; it *does* take a fair amount of effort, in many countries, to change those rules. I ask this because it seems to me that a file containing several years of Daylight Savings Rules can be expensive to search You don't search the file; you load the whole thing and search a table. Several techniques can be done (e.g., binary search), to make that search faster. and a program to calculate Daylight Savings time for multiple years is unnecessarily complex. No, it is *not*! The code merely searches a table; the complexity of the code is independent of the size of the table.

1 0

When to use DST rules
by seismo!celerity!dreamit!jjw Feb. 20, 1987

Feb. 20, 1987

All the versions of ctime that I am familiar with apply the daylight savings time rules into the "distant" past and into the future. This seems like overkill. Certainly, people want to see the time with DST applied for the current year and it probably makes sense to apply the DST correction for the previous year. But is it really necessary to apply the DST rules when listing times for data which is 2, 3, 5 or 10 years old? Since the DST rules are subject to the whims of politicians and bureaucrats, any rules beyond the next year are as likely to be wrong as right. I ask this because it seems to me that a file containing several years of Daylight Savings Rules can be expensive to search and a program to calculate Daylight Savings time for multiple years is unnecessarily complex. If we only need to determine the rules for the last couple of years, and for the next year, then time conversions will be faster and simpler.

1 0

code for mktime()?
by seismo!nbires!vianet!devine Feb. 20, 1987

Feb. 20, 1987

Has anybody tried to write the mktime() function? If so, please send it to me. If not, I'll write it. Bob Devine

1 0

Re: mktime
by seismo!cbpavo.MIS.OH.ATT.COM!mark Feb. 14, 1987

Feb. 14, 1987

However, I can certainly see uses where converting from some other timezone would be a nice ability to have - especially parsing rfc822 style Date: lines. But I think this is a pretty specialized usage, there aren't that many other applications where the necessary zone information is going to be available in just the right form. It's not specialized at all. UNIX already provides two different timezones: localtime and gmtime. If we're going to provide an inverse to localtime, where does that leave the inverse to gmtime? Most places where times are used with the zone included, the zone is converted to its zone name form, and that is not an invertible operation - there is no definable mapping from zone names to numeric offsets, so the ability to make this transformation correctly isn't going to happen all that often. I gather you don't read ISO standards or RFC's 822 or 850. The ISO standards have you say "+hhmm", e.g. +1030 or -0500. 822 and 850 let you say EST or PDT or whatever for the USA timezones, but recognizing that this convention doesn't extend outside the USA, require that the explicit zone offset be used for other zones. What's more, in cases where I simply want to convert a local time in struct tm format to a time_t, I am not necessarily going to know what the zone is. Consider the use of mktime() inside date(1). Some user types a date/time which is easy to parse into a struct tm, from there it should be possible to use mktime() to get the time_t. But if you have to know the zone first things aren't nearly that easy. It certainly isn't a constant - it depends on the particular time that the user typed. Some applications will have a default time zone (the local one), others will default to UT. But with a struct tm that was generated by gmtime or localtime; we should expect that these routines filled in the appropriate value. If we got a date string from another machine (mail, news, network transaction) the time zone should be extracted from it. I have a couple of misgivings about your implementation though. I'm not sure exactly what the point of having 2 fields for hours and minutes is - that assumes that the offset is an even number of minutes (no odd seconds) which while likely, isn't something I would want to bet my life upon (I would assume that the USG people assumed it likely that there would be no minute offsets, only even hours when doing the standard Sys III/Sys V implementation...) So, I would suggest a single field that contains the offset in seconds from GMT. In principle I agree that seconds is a better way to do it. I note, however, that minutes was good enough for ISO, and I have been unable to get any evidence that there are places that have their timezone an offset from UT that isn't an even minute. Secondly, I'm not sure why you chose to have West of Greenwich being negative. All previous uses of timezone offsets in Unix have been the other way - West of Greenwich positive. I know that the ISO standard defines it as West == negative, but its surely an arbitrary choice, its trivial to negate the value anywhere an ISO form of offset is needed, and keeping this compatability with current (old) usages (from v6 through 4.3bsd, and pwb to Sys V) certainly seems to be a worthwhile objective. I'm sorry, but given a choice between a well defined ISO standard and a egocentric UNIX implementation, I don't see any excuse for violating the ISO standard. Upward compatibility may require that external variables like timezone, TZ, or the ftime system call remain backwards for upward compatibility, but we're defining a new function here. Hell, TZ and ftime aren't even to seconds resolution, anyway. Mark

2 1

Re: mktime
by seismo!sun!guy Feb. 11, 1987

Feb. 11, 1987

> unlikely that somebody would actually wait for some moment of time by > looping and repeatedly testing the current time, as given in the > Rationale. I believe that this is exactly what "cron" does. At least, some forms of cron. The example given in the rationale, although admittedly skeletal, didn't seem to do anything to block execution, which seems odd, although on a system that doesn't support multitasking I suppose it's not too unreasonable. "cron" does a "sleep" or "alarm"/"pause" here. It can do that because it's running under UNIX, which means it also knows that "time_t" is a straightforward arithmetic type, and thus doesn't need the "mktime" jiggery-pokery that's in the ANSI C standard. If you're writing C programs that purport to be able to run on several different OSes, you probably don't want them to spin waiting for some time to arrive; you are better off throwing in #ifdefs or an OS-interface module and using the native OS facilities for blocking until some particular time or for some particular length of time. (If the ANSI C committee is trying to to make it possible to write programs like this to run in a "pure C" environment, without requiring any OS services, they're making a mistake.) Once you get to that point, you can use "time_t" as an integral type if you're writing for a UNIX/POSIX environment, or use whatever other native timing facilities other OSes provide.

1 0

Re: mktime
by seismo!hadron!jsdy Feb. 11, 1987

Feb. 11, 1987

----- Transcript of session follows ----- bad system name: elsie uux failed. code 101 554 elsie!tz... unknown mailer error 101 ----- Unsent message follows ----- Date: Wed, 11 Feb 87 10:31:58 est From: jsdy (Joseph S. D. Yao) To: seismo!sun!guy Subject: Re: mktime Cc: elsie!tz (Guy:) > unlikely that somebody would actually wait for some moment of time by > looping and repeatedly testing the current time, as given in the > Rationale. I believe that this is exactly what "cron" does. At least, some forms of cron. I do want to support Guy's suggestion of a canontime() and full arithmetic support. Joe Yao hadron!jsdy(a)seismo.{CSS.GOV,ARPA,UUCP} jsdy(a)hadron.COM (not yet domainised)

1 0

Re: mktime
by seismo!cbpavo.MIS.OH.ATT.COM!mark Feb. 11, 1987

Feb. 11, 1987

The new, improved 'tm' has two offset fields: struct tm { /* all current fields */ time_t tm_tzdiff; time_t tm_dstdiff; char* tm_tzname; }; One would add in the tm_dstdiff if tm_isdst is true, otherwise only the tm_tzdiff is added. The mktime() call need not be concerned with translating time zones to hour:minute offests from UT, it only needs to churn through the calculations for the structure members. Ron Tolley suggested that the tm_tzdiff and tm_dstdiff values can be rolled into a tm_tzadj. I prefer the flexibility offered with the two separate values. Calculations on the 'struct tz' can more easily deal with the DST boundary conditions if both values are distinct. I would prefer to see them rolled into one offset, representing the offset that applies to whatever time is actually in the rest of the fields. My reasoning is that most programs don't care whether DST is in effect or not, they just want to know what's there. Such programs will have to always write code like this: tmp->tm_isdst ? (tmp->tm_tzdiff+tmp->tzdstdiff) tmp->tm_tzdiff instead of the far simpler tmp->tm_tzdiff Also, any program that CREATES a struct tm is going to have to figure out whether to apply dst or not, a task I don't envy. If you want to record what the dst offset was, fine, but it should be an optional component the way isdst is, that is, the tzdiff field can stand alone without it, and if dstdiff isn't filled in, it doesn't matter. What I'm suggesting here is that if the time is T+Z+D, then tzdiff would contain Z+D and dstdiff D (or -D, if you prefer); you were proposing that they contain Z and D, respectively. Mark

1 0

Re: mktime
by seismo!nbires!vianet!devine Feb. 10, 1987

Feb. 10, 1987

This message is on the mktime() function and a new struct tm. Mark Horton says: > If we're to view mktime as a general-purpose converter from struct tm > to time_t, there's a gotcha waiting: struct tm doesn't contain any > time zone information (the isdst flag doesn't help) and hence this > conversion is ambiguous, unless you assume the local time zone or gmtime > or some such thing. That's not a good assumption to make. > > In my implementation, I added two fields to struct tm, for the hours and > minutes in the time zone which resolved the ambiguity. kre says: > So, I would suggest a new function to handle mktime() with a supplied > zone, which would look at extra info in the struct tm. > So, I would suggest a single field that contains the offset in seconds > from GMT. To repeat a suggestion I made a couple of months ago, let's extend 'struct tm' with fields to reduce the ambiguity. Consider that if someone hands you a 'struct tm' without providing usage information, it is worthless because you don't know its base. The same argument applies to many other date/time representation. The new, improved 'tm' has two offset fields: struct tm { /* all current fields */ time_t tm_tzdiff; time_t tm_dstdiff; char* tm_tzname; }; One would add in the tm_dstdiff if tm_isdst is true, otherwise only the tm_tzdiff is added. The mktime() call need not be concerned with translating time zones to hour:minute offests from UT, it only needs to churn through the calculations for the structure members. Ron Tolley suggested that the tm_tzdiff and tm_dstdiff values can be rolled into a tm_tzadj. I prefer the flexibility offered with the two separate values. Calculations on the 'struct tz' can more easily deal with the DST boundary conditions if both values are distinct. Bob Devine

1 0

West of Long 0 : Pos or Neg?
by seismo!nbires!vianet!devine Feb. 10, 1987

Feb. 10, 1987

Mark Horton says: > In my implementation, I added two fields to struct tm, for the hours and > minutes in the time zone which resolved the ambiguity. > (both are negative for us in the USA) kre says: > Secondly, I'm not sure why you chose to have West of Greenwich being > negative. All previous uses of timezone offsets in Unix have been > the other way - West of Greenwich positive. I favor the ISO rule. Every international organization (but, I'm sure there are exceptions) has adopted the East of Longitude 0 is positive; west is negative. If we are proposing POSIX as an international standard, we should accept the international rules. The UNIX convention is unfortunately wrong. It was one of those 50/50 chances (like determining whether the flow of electicity is positive or negative) that was incorrectly chosen. Dems da breaks. Bob Devine

1 0

Re: mktime
by seismo!cbpavo.MIS.OH.ATT.COM!mark Feb. 8, 1987

Feb. 8, 1987

If we're to view mktime as a general-purpose converter from struct tm to time_t, there's a gotcha waiting: struct tm doesn't contain any time zone information (the isdst flag doesn't help) and hence this conversion is ambiguous, unless you assume the local time zone or gmtime or some such thing. That's not a good assumption to make. In my implementation, I added two fields to struct tm, for the hours and minutes in the time zone (both are negative for us in the USA; well, I guess -0 is still 0 for the minutes) which resolved the ambiguity. I'm not sure if this change can be made in general without breaking things, and it could have been done with one field. The offset defines the tme zone the actual value in the struct tm is in; the isdst flag doesn't really have anything to do with it. Mark

2 1

Re: mktime
by seismo!sun!guy Feb. 7, 1987

Feb. 7, 1987

I'm not sure if this got out, so... 1. What other reasons can folks think of for adding mktime to the standard? The reason I've wished UNIX had such a function is that it can be useful to have an inverse to "localtime". I'm not sure it really needs to be in the standard, though; there are things that can be done in a C environment (one that is not necessarily a UNIX/POSIX environment) with the results of "localtime" or "ctime" (namely printing them), but I'm not sure what you can (or, at least, would want to) do with a time value converted from local time. It seems unlikely that somebody would actually wait for some moment of time by looping and repeatedly testing the current time, as given in the Rationale. In a UNIX/POSIX environment, "mktime" would be quite useful. I'm not sure whether it needs to be present in all C environments or not. Perhaps X3J11 should hand it over to 1003.1? (If they do, I can think of a few other things they should hand off as well!) 2. Would it be wise to add a function to the standard to permit arithmetic on time_t type values? There already is one such function, namely "difftime". A function like "addtime" (although possibly with a "double" rather than an "int" argument, since "difftime" returns a "double") not only fits in well with "difftime", but provides a capability that is missing. It's like pointer subtraction and pointer/integer addition; having the former without the latter seems silly. 3. If an arithmetic-permitting function was available, would it be wise to eliminate the ability to handle tm structures containing "out of bounds" values from mktime? I'd be inclined to do so; I don't see the reason why they even put the ability to handle "out of bounds" values now. It seems to me that a program could just as well do the mixed-radix arithmetic entirely by itself, without getting a half-assed assist from "mktime", which seems to be what they intended. They should either have provided a function to add two "struct tm"s (where the second one represents an interval, and need not represent a valid time - e.g., you could represent "25 hours" either by "tm_hour" being 25 or "tm_min" being 25*60), or, at least, provided a separate function to "canonicalize" a "struct tm", instead of burying it in "mktime" (I could imagine a program wanting to do arithmetic on dates and times with both the values and the result being in mixed-radix form, so that they would never bother with any "time_t" value).

1 0

resolution of TZ variable?
by seismo!nbires!vianet!devine Feb. 6, 1987

Feb. 6, 1987

I'm not sure if a consensus was ever reached on the definition of how to store information about what timezone for a user. My suggestion is that "TZ" is acknowledged as the place where the timezone choice is placed. But no definition of what the string looks like is given for POSIX. It is an implementors decision as to what is placed there -- file name, TZ rules, or magic string. On this point a "should" should be used to guide the implementor in a reasonable direction (ie one of the 3 ways listed, don't come up a 4th version). Bob Devine

1 0

Re: mktime
by seismo!nbires!vianet!devine Feb. 6, 1987

Feb. 6, 1987

Arthur suggests: > If the *only* reason for adding mktime was "to replace the capability to > do. . .arithmetic [on time_t type values]," I'd advocate simply throwing > mktime overboard ... > 1. What other reasons can folks think of for adding mktime to the standard? I would favor it just for conversion from a 'struct tm' to a 'time_t'. Lord knows that I looked at enough incorrect versions where someone tried to write it themselves and got lost! Don't ask about my first attempt several years ago... > 2. Would it be wise to add a function to the standard to permit arithmetic on > time_t type values? If there are no functions to modify a time_t or to compare one, people will invent several versions. However, this should be a C question. Can the existing practices of using 'long' variables be supported? Didn't the X3J11 people provide some functions? Can one cast from a arithmetic type to a time_t (and still get something reasonable)? I'm not sure this last question can be done if time_t is defined by a manufacturer. I favor providing only a mktime() call and guarentee the portability of arithmetic operations on the fields of a 'struct tm'. > 3. If an arithmetic-permitting function was available, would it be wise to > eliminate the ability to handle tm structures containing "out of bounds" > values from mktime? I don't understand what you mean by "out of bounds" -- the added structure members? bad data for a member? Bob Devine

1 0

Colorado Time ?!
by seismo!nbires!vianet!devine Feb. 6, 1987

Feb. 6, 1987

I have been in contact with the state representative here in Colorado who will soon be introducing a resolution in a committee to change the time zone for Colorado. This is of interest to all the folks in this TZ discussion group because of the ramifications that may result from this effort. You can skip the background info. Background:: 1. Denver Colorado (and increasingly other metro areas along what is called the Front Range) suffer from the growing pollution concerns caused by more and more people and their cars. The air quality grows particularly bad during "inversion layers" occurring in winter. Denver's problem come from very high levels of carbon monoxide. Pilots call Stapleton (5th largest airport in world) "hot and high" because of the thin air at the city's altitude. There is not much oxygen in a given volume as there is at sea-level. Mexico City has the same kind (though MUCH worse) problem. Automobile exhaust heavily taxes the capacity of the local atmospheric conditions. 2. Given the fixed problem of lots of people already living there, how is it possible to reduce CO levels? Voluntary no-drive days have been tried with minimal effect. No-fireplace laws are being passed that forbid burning on high-pollution days. Vechicle emission tests are required annually. 3. Automobile exhaust has been estimated to be 75% of the CO source. 4. Moving the night-time rush hour earlier in the day so that the warm air (temperatures drop rapidly at dusk) can more readily handle that CO hit would help reduce the average CO level by 10% and would really reduce the peak CO level. Time zone implications:: ------------------------ There are two ways that Colorado could move that evening rush hour: 1. Move to a different time zone. 2. Have year 'round daylight saving time. Way # 1 makes a lot more sense. BUT, to do so requires the approval of the US Dept of Transportation who will only seriously consider a TZ move if it is for "the convenience of commerce". So, any proposal that attempts to deal with TZs and DST may get hit with way # 2. Plan your design accordingly. I'll send more information when this issue is before the committee. Bob Devine

1 0

Timezone variations
by seismo!celerity!dreamit!jjw Feb. 6, 1987

Feb. 6, 1987

After a long discussion of the variation in European timezones seismo!mcvax!cwi.nl!dik (dik t. winter, cwi, amsterdam, nederland) states: > So what is my conclusion? It is nice to automatically switch to and from > DST, however it must be easily possible to override the rules. (In some > countries in Europe during the period 1977-1982 it was not known until a > few days in advance whether a switch would occur or not, and what day it > would occur!) The problem occurs when the rules are embedded in a library routine or a difficult to change file. If the DST rules for the local time zone are kept in a file which can be easily and quickly edited then this can be done very quickly when necessary by those who should know (people living in the local time zone). Rather than a file of rules I prefer a file of change dates along with information about how much time is to be added or subtracted and the appropriate time zone name. The format should allow for partial hours, negative savings ("daylight spending time"?) and double daylight time. Arthur Olsen's timezone compiler generates a file of the proper type. However, I am not sure it provides the necessary flexibility for quick local changes of all types.

1 0

European time zones [forwarded message from cgcha!wtho]
by Arthur David Olson Feb. 4, 1987

Feb. 4, 1987

I've attached a note I received from Tom Hofmann, slightly edited at Tom's request. --ado ... Date: Wed, 28 Jan 87 16:56:27 -0100 From: seismo!mcvax!cgcha!wtho (Tom Hofmann) Message-Id: <8701281556.AA22174(a)cgcha.uucp> ... Subject: Time zone handling ... ... Let me say something about European time rules. First of all, I'm surprised to find the zone MET for Central Europe in file 'europe'. The correct expression is CET (Central European Time), although it's not the first time I found the expression MET. Maybe the best is a link between MET and CET. Secondly, the European time rules are much more complex than described in 'europe'. It is standardized since 1981, when most European countries started DST. Before that year, only a few countries (UK, France, Italy) had DST, each according to national rules. In 1981, however, DST started on 'Apr firstSun', and not on 'Mar lastSun' as in the following years. So we should set 1981 for FROM, and ignore the past. But also since 1981 there are some more national exceptions than listed in 'europe': Switzerland, for example, joined DST one year later, Denmark ended DST on 'Oct 1' instead of 'Sep lastSun' in 1981---I don't know how they handle things now. Finally, DST is always from 'Apr 1' to 'Oct 1' in the Soviet Union (as far as I know). 'europe' should be corrected in that sense, but perhaps you better make a query to Usenet first---maybe you'll find somone who knows more about national exceptions to European time rules. Tom Hofmann, Scientific Computer Center, CIBA-GEIGY AG, 4002 Basle, Switzerland UUCP: ...!mcvax!cernvax!cgcha!wtho

1 0

Re: mktime
by seismo!cbpavo.MIS.OH.ATT.COM!mark Feb. 1, 1987

Feb. 1, 1987

I was VERY VERY happy to see mktime, as it turned out to be just what I needed for an application I'm supporting. (Actually, I had to alter it somewhat - the major change was that mktime speaks local time, and I needed a function that spoke UTC. Easy when I had the source, but it's worth mentioning that the UTC flavor is also useful.) What did I need it for? Well, I'm supporting a set of routines that provide X.410 style transactions over a network. These transactions have time stamps in them, and the time stamps are in ASCII, in a format that conforms (almost) to the appropriate ISO standards. These routines are mostly a cut up ctime.c, but I also had to supply functions to take strings received over the network (which are always in UTC) and do things like convert them to local time (for logs and for machines that keep time in local time), add N hours, etc. I'm enclosing the manual pages for my routines (the code itself is, I'm sorry to say, considered proprietary to AT&T, but the interface is open.) I consider this just an expedient solution, and not necessarily the end-all wonderful solution. Note that it does not provide a routine like mktime to the users, since I want to hide the time_t time from the users. (We have to worry about birth dates of parents of people alive today, so the 32 bit time_t isn't adequate. I don't really support that yet, but I don't provide user access to time_t so they won't write code now they'll be sorry for later.) Mark .TH ISODATE 3I .SH NAME isonow \- create ISO format string describing current date/time isodcmp \- compare two ISO format dates iso2local \- convert ISO date to local time iso2gmt \- convert ISO date to UTC time isoadd \- add a fixed offset to an ISO date .SH SYNOPSIS .nf .B "char *" .B "isonow();" .sp .B "int" .B "isodcmp(d1, d2);" .B "char *d1, *d2;" .sp .B "char *" .B "iso2local(date)" .B "char *date;" .sp .B "char *" .B "iso2gmt(date)" .B "char *date;" .sp .B "char *" .B "isoadd(date, days, hours, minutes, seconds)" .B "char *date;" .B "int days, hours, minutes, seconds" .fi .SH DESCRIPTION .P These routines manipulate ISO format date/time strings, as defined in the MDTP specification. Other routines may be added, as needed, later. .P .I isonow returns a character string, in ISO format, describing the current date and time. Only one of the ISO choices is used, namely: .nf yyyymmddhhmmsszzzzzE for example 19850410142954-0500E or 19850410142954+0930E or 19850410192954ZE .fi The first date is in the USA Eastern time zone, the second in the Australian Central time zone, and since isonow always returns GMT, the third sample is more typical. The trailing E means .I exact , as opposed to B for .I before or P for .I post (after.) .P .I isodcmp compares two ISO format times, telling which is earlier. It returns \-1 if the first is earlier, 0 if they are the same, and +1 if the second is earlier. .P .I iso2local takes an ISO format date (in either Z time zone, local time, or any other time zone) and converts it to the local time zone. It returns a string in ISO format indicating the local time zone. .P .I iso2gmt takes an ISO format date (in any time zone) and converts it to the Z (GMT) time zone. It returns a string in ISO format indicating the Z time zone. .P .I isoadd takes an ISO format date (in any time zone) and adds the given number of days, hours, minutes, and seconds to it. The numbers may be positive or negative. It returns a string in ISO format indicating the Z time zone. .SH BUGS In the interests of speed, .I isodcmp does not work correctly if any other variant of ISO format is used (e.g. seconds are missing, or a Z time zone is used, or a precision is included), or if the two time zones are not the same.

1 0

a timezone list addition
by seismo!ut-sally!zotz.cs.utexas.edu!jsq Jan. 31, 1987

Jan. 31, 1987

>From: ames!scubed!ncr-sd!greg(a)sally.utexas.edu To: milano!im4u!ut-sally!std-unix(a)sally.utexas.edu Date: Thu, 15 Jan 87 16:16:56 pst Message-Id: <8701160016.AA04029@scubed> Subject: Re: time zone mailing list Newsgroups: mod.std.unix In-Reply-To: <6835(a)ut-sally.UUCP> Organization: NCR Corporation, Rancho Bernardo In article <6835(a)ut-sally.UUCP> you write: >Any interested mod.std.unix readers can mail me a request to be added. Sigh. I'm not sure I should do this after my last attempt at commentary met with such disaster, but could you put me on the list? Tks. Oh, I'm Greg.Noel(a)SanDiego.NCR.COM or greg@ncr-sd, whichever your software will accept. -- -- Greg Noel, NCR Rancho Bernardo Greg(a)ncr-sd.UUCP or Greg(a)nosc.ARPA

1 0

mktime
by Arthur David Olson Jan. 30, 1987

Jan. 30, 1987

Now that new requests for addition to the tz mailing list have tapered off (and now that the snows have stopped here in the Washington, D.C. area) I'd like to note a problem in the October, 1986 version of the Rationale document that accompanies the draft proposed C standard, and then ask some questions. The part of the Rationale document that I'm troubled by is section 4.12.2.3 on the mktime function: > mktime is an invention of 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; > > /* ... */ > time(now); > 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 semantics 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 > funciton 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. Ignore the grammar and coding errors for the moment. The big problem (to me) is that code like the above is not a "paradigm for continuing some loop for an hour"--you may end up continuing the loop for two hours (or for no time at all) if the loop is executed just before a daylight saving time transition. If the *only* reason for adding mktime was "to replace the capability to do. . .arithmetic [on time_t type values]," I'd advocate simply throwing mktime overboard and specifying a function such as time_t addsec(time_t base, long seconds) to allow the arithmetic to be done. But the Rationale says that allowing such arithmetic is just "[o]ne of the reasons." And now, the promised questions: 1. What other reasons can folks think of for adding mktime to the standard? 2. Would it be wise to add a function to the standard to permit arithmetic on time_t type values? 3. If an arithmetic-permitting function was available, would it be wise to eliminate the ability to handle tm structures containing "out of bounds" values from mktime? -- UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado(a)seismo.ARPA DEC, VAX, Elsie & Ado are Digital, Borden & Ampex trademarks.

1 0

New time zone bundles available
by Arthur David Olson Jan. 3, 1987

Jan. 3, 1987

New shell archives of time zone programs and data are available; folks who are interested in getting copies should send me a note. In the new bundles I've switched from having a int settz(char * zonename) function to set the time zone to having two functions: void tzset() which sets the time zone according to the environment variable TZ, and void tzsetwall() which sets the time zone to the best available approximation to local wall clock time, regardless of what's in TZ. While several folks on the mailing list have expressed a preference for settz over tzset/tzsetwall, I can't help but believe that system vendors (who'll eventually have to bless any new standard) would favor using tzset to increase forward portability. (I'd appreciate comments on this point--unofficial and of the record, if need be--from those of you who work for system vendors.) The new bundles also include source (though, as yet, no documentation) for the POSIX mktime function; this source is a merger of work done by Guy Harris and work done by Robert Elz. I hope to submit a new time zone package to mod.sources fairly shortly. Two upcoming dates motivate this: the date on which DST rule changes take effect in the US (April 5), and an upcoming P1003 meeting in March. The more you good folks can work things over before they go off to mod.sources, the happier I'll be. -- UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado(a)seismo.ARPA DEC, VAX, Elsie & Ado are Digital, Borden & Ampex trademarks.

1 0

Re: Parsing /etc/TIMEZONE
by seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt Dec. 21, 1986

Dec. 21, 1986

One thing that bothers me about the new parsing routine for /etc/TIMEZONE (I can't say at this point whether it is different from the old one) i that fgets calls malloc(). One of the uses which I have for ctime strictly forbids the use of either malloc() or the standard I/O libraries. Ron Tolley

1 0

Re: Default timezone
by seismo!sun!guy Dec. 20, 1986

Dec. 20, 1986

I mean local wallclock time (conversion rules out of an instruction would be a little wierd... but this processor has a "load.time" instruction, or something like that, which returns local wallclock time, 64 bits, high precision, and lasts forever...) By "local wallclock time", do you mean local wallclock time (DST and all), or just the number that it was originally set to at time T plus the number of clock ticks since time T? If it's the latter, it could just as easily keep "UNIX time". The time system call (I can't remember now if its in the kernel or not or if time(2) just does this in each user's code) gets that value and then applies basically the reverse transformation of localtime() to get GMT to return to the user... My point was that the method of discovering what local wall clock time is shouldn't be constrained at all in the standard. But in most cases you get wall clock time by doing "time" or "gettimeofday" and feeding that to "localtime"; if you do that on this machine, and it's OS is really UNIX-compatible, the fact that the hardware keeps some flavor of local time is irrelevant. The application would get "UNIX time", and then call "localtime" to convert that back to local time in some time zone. The standard *already* constrains the way you discover what local wall clock time is; you get "UNIX time" from "time" and feed it to "localtime". Hardware that keeps "wall clock time" is, in a POSIX system, an obstacle to overcome (you have to convert "wall clock time" to "UNIX time") rather than something that makes certain operations easier. If you really don't want the standard to constrain how you get local wall clock time, you'd have to add a function like "localtime" that takes *no* arguments, and returns the broken-down value of the wall clock time, or add a function like "time" that returns wall clock time as a "time_t" and use "gmttime" or something if you want to break that down. The S5R3.1 scheme does handle this, by having "init" put the time zone in its environment. No, that only gets it to the children of init, and their children, until someone types "env - sh" to their shell... How is typing env - sh to your shell different from typing TZ=Europe/Albania; export TZ to your shell? In either case, the user is explicitly reaming out their environment. Are you saying that even if a user reams out their environment, programs they run should get local time by default? I neither agree nor disagree with this; I haven't seen what I consider to be a good argument either way. Actually, "settz()" could be implemented in the S5R3.1 scheme. Yes, the problem is whether AT&T will do it or not. Since some way of permitting a program to get all time conversions to be done with the "official" local rules is required, the standard must include something like that. The S5R3.1 scheme already has a way of doing it; you open "/etc/TIMEZONE", read it, and "putenv" the value in there. However, 1) you don't want to have to write the same idiom 500 times for 500 programs, and 2) you want the standard to have a way of requesting "official" local time without having to know so many details of how the rules are specified, so that the standard doesn't have to require you to use TZ and all the baggage (i.e., the ability for the user to choose which rules they want) that this drags in. So you want some way of saying "please give me local rules", rather than some way of getting the "name" of the local rules and some way of saying "please give me this set of rules". "settz((char *)NULL)" seems fine to me. (The behavior when "settz" is passed a string rather than a null pointer could be left up to the implementation, in case any implementor might object to a fully general scheme.) If the standard does include that, AT&T could implement it, and would have to if they wanted to sell to somebody who required POSIX compliance.

1 0

Re: Default timezone
by seismo!sun!guy Dec. 20, 1986

Dec. 20, 1986

While I agree that setting TZ in the environment is best used for a user modification of the default, you have to admit that an implementation that read /etc/timezone every time you did an ls -l or called ctime for logging would be awfully slow. Not really. I tested Arthur Olson's code, which doesn't read "/etc/TIMEZONE" but *does* read a file of rules, with a program that just converted the current time using "ctime". The difference in time was negligible. It probably took more time to load the test program(s) than it took to read the files - and this was a version that read files that were written with a machine-independent byte order; it wasn't just doing one big "read". Even using Sun XDR, it wasn't a major difference. (Also, remember that a program won't read "/etc/timezone", or the setup files, *every* time it calls "ctime"; once is enough. Yes, this means you have to restart long-running programs if the rules change, but that shouldn't happen too frequently.) This is why I liked the ftime system call notion; it's impossible to forge, easy to default, easy to configure, and fast. Unfortunately, it's also incomplete, unless you extend "ftime" to return a table of DST on/off times. Recompiling every program that uses "ctime" because the U.S. Congress extended DST is a pain; it's worse in countries that seem to change the rules on a yearly basis....

1 0

Re: Default timezone
by seismo!cbpavo.MIS.OH.ATT.COM!mark Dec. 19, 1986

Dec. 19, 1986

While I agree that setting TZ in the environment is best used for a user modification of the default, you have to admit that an implementation that read /etc/timezone every time you did an ls -l or called ctime for logging would be awfully slow. This is why I liked the ftime system call notion; it's impossible to forge, easy to default, easy to configure, and fast. Mark

1 0

Re: Default timezone
by seismo!sun!guy Dec. 18, 1986

Dec. 18, 1986

> From: seismo!cuuxb!dlm (Dennis L. Mumaugh) > Subject: Default timezone > Our reasoning is that in the majority of cases this is an error > by the system administrator in setting or exporting the TZ > variable and it is necessary for someone to notice the error. As > it stands most developers/porters set the TZ to their local time > zone (who is it that uses PST?!) and then never notice that their > product has problems. What "problems" does setting TZ to the local time zone (which *IS* PST here where we do *our* development) disguise, and why does defaulting to GMT if TZ is missing or empty reveal them? > Using wall clock as default merely propogates this development > problem and results in products having problems when they are > used in other environments. So does setting TZ in "/etc/init". The only way to flush these problems out before the product is released is to *deliberately* run it with timezones other than the developers' zone. > From: seismo!cuuxb!dlm (Dennis L. Mumaugh) > Subject: Re: Parsing /etc/TIMEZONE > I do like the idea of a single place for establishing the TZ for > a system. It makes it very easy for new administrators. Olson's scheme has this, as well; you just use the "-l" flag when running "tic". It causes a link name "localtime" to be made to the time zone specified as the argument to "-l". > Another problem with a routine to read and parse /etc/TIMEZONE is > what does one do for non-ATT shells (c shell and others) the > setting of TZ in the environment differs. That's why having > /etc/init set things up is good. That guarentees a "standard > environment". It is true someone could diddle with it, but I am > more concerned with naive users than others. You're going to need a routine to read and parse "/etc/TIMEZONE" anyway. "uucico" will have to use it; it does NOT want to use "TZ" to indicate what the local time zone is, precisely *because* somebody could diddle with it. > From: Robert Elz <seismo!munnari!kre> > Subject: Re: Default timezone > Date: Wed, 17 Dec 86 11:09:09 cst > From: cuuxb!dlm (Dennis L. Mumaugh) > Message-ID: <8612171709.AA08584@cuuxb> > The issue here really, is how does a programmer exercise his > "conscious choice" to get wall clock time? > If you wanted to define /etc/TIMEZONE or something as a > file containing the right TZ string, so that programs that > need wall clock time would be required to go read (and parse) > that file, then that would be a solution. But you had better > be prepared to define the format and name of that file, > and stick to it forever more. You should also be prepared > to go and find all the standard processes that need this > (like uucico, and others) and insert the relevant code. Actually, any scheme would require you to find all the processes that understand this, and insert some code to ensure that the machine's time zone is used. > Personally, I prefer a slightly simpler interface. That > doesn't preclude putting the information in a file, of > whatever format you prefer, but it should be the time > functions that read the file, not the user's code. Absolutely. This could be done in the S5R3.1 scheme, by providing a function to read "/etc/TIMEZONE". You could even call this function "settz()" (see below). > This also allows for more implementor flexibility, she > has lots of choices she can make as to how to obtain > the local wallclock time - from a simple ascii file, > from a precompiled binary file, from a network information > server, from the kernel via a system call, and I assume > lots of others. I can even imagine processors where local > time might be available as an instruction in the instruction > set (I can imagine such processors because we have one...) Do you mean "local wallclock time" or "local conversion rules"? With current UNIX interfaces, and with all the proposals that have popped up so far, all you could do is get the latter and use them to convert the result of "time()" to local wallclock time. > Certainly having local wall clock time be the default > when TZ is not set is a very sensible way to do things, > as it means that the system administrator doesn't need > to set up TZ for every process in the system, The S5R3.1 scheme does handle this, by having "init" put the time zone in its environment. > Most of the people on this list seem to feel that the > right way for a program to choose wallclock time explicitly, > is to putenv() TZ to a null value. Personally, I still think > settz() is a cleaner interface. Actually, "settz()" could be implemented in the S5R3.1 scheme. Assume that the time conversion code takes some string and uses it to set up the conversion rules (details deliberately left unspecified). "tzset" would use the value of 'getenv("TZ")' for this string. "settz" would do the following: if its argument is a null pointer, read "/etc/TIMEZONE" and use the string located therein; if its argument is a pointer to a null string, use GMT; otherwise, use its argument as the string in question. There is one issue here; should a process only be able to affect how its UNIX time <-> local time conversions are done, or should it also be able to affect any children it spawns? The former is effected by "settz"; as it stands, the later requires you to change TZ, either by eliminating it, nulling it out, or setting it from "/etc/TIMEZONE". "uucico" would probably want to affect its children; some other program might not. I do have another question; are we discussing UNIX or POSIX here? If the latter, should POSIX require that anything be supported other than local machine time? It may be convenient to permit users to specify other time zones, but user convenience is somewhat outside the scope of 1003.1, at least. POSIX should not *preclude* a user overriding the default time zone, and as such must provide a way for a process to override the user's override and get the default timezone; it probably must also provide a way to force its children to use the default time zone, as well. For this, all you need is a function that says "set time zone to the default"; the full generality of "settz" isn't necessary. You could have POSIX just define the behavior of "settz(char *)NULL)" and leave the rest up to the implementation. POSIX must also require that an application must, by default, get some "reasonable" time zone information, which would either be the system default time zone or, if supported, a user-specified time zone. It must do so in such a way that no application need explicitly set up anything (such as snarfing the right value of TZ from "/etc/TIMEZONE") in order to get this information, and in such a way that no application need be run in a special environment (i.e., saying "the way you set it is to put it in "/etc/profile" is out). Olson's scheme provides most of what is needed from the POSIX standpoint. "settz" could be added to the S5R3.1 scheme, and it would be equivalent (from the program's standpoint) to Olson's scheme. Both Olson's scheme, and the S5R3.1 scheme with "settz" added, would provide a way for a program to explicitly choose a particular time zone (and it would work in the same fashion in both schemes), and would use the value of TZ if one was provided. Both schemes make it simple for an administrator to set the default timezone; in Olson's scheme, you just run "zic" with the "-l" flag specifying the default zone, or make the link yourself, and in the S5R3.1 scheme you just set the "/etc/TIMEZONE" file. Neither scheme directly addresses the question of "how do you teach your children about the time zone you selected"? One way to do this would be to use "putenv"; however, that exposes various implementation details that really should not be exposed. Perhaps there should be a function like "settz" that propagates that change to children.

1 0

Re: Parsing /etc/TIMEZONE
by seismo!cuuxb!dlm Dec. 18, 1986

Dec. 18, 1986

Yes, it is true that my parse routine does use standard IO. Also it is simple minded about "shell". It doesn't know about quoting or shell escapes: thus the new expanded TZ will break as there is a semi-colon in the TZ string. Oh well, what do you want for free? BTW, the init parser for SystemV Release 3.1 is not very smart either. I do like the idea of a single place for establishing the TZ for a system. It makes it very easy for new administrators. Another problem with a routine to read and parse /etc/TIMEZONE is what does one do for non-ATT shells (c shell and others) the setting of TZ in the environment differs. That's why having /etc/init set things up is good. That guarentees a "standard environment". It is true someone could diddle with it, but I am more concerned with naive users than others.

1 0

Default timezone
by seismo!cuuxb!dlm Dec. 18, 1986

Dec. 18, 1986

The issue of what time zone to use if the TZ variable is not set should be thought out a bit more. ATT has decided to use a "default" of GMT if no TZ is set or if it is NULL ( "TZ=" ). Our reasoning is that in the majority of cases this is an error by the system administrator in setting or exporting the TZ variable and it is necessary for someone to notice the error. As it stands most developers/porters set the TZ to their local time zone (who is it that uses PST?!) and then never notice that their product has problems. Using wall clock as default merely propogates this development problem and results in products having problems when they are used in other environments. The use of wall clock as the "default" ought to be a concious choice by a programmer and GMT ought to be the default whenever a time routine can't decide what timezone to use.

2 1

Resolved timezone issue? Other issues. New ctime manual page
by ado Dec. 16, 1986

Dec. 16, 1986

In this letter I'll try to: 1. Recap the discussion of the question "Should TZ, or something else (such as TIMEZONE), be used as the environment variable where time zone information is kept?" 2. Throw in my own two cents on the discussion of "How does the environment variable TZ get initialized in the first place?" 3. Summarize different ways programs might use to get time zones other than the one specified in the environment--I trust other folks will discuss this further. I've also attached a copy of my latest revised ctime manual page. 1. A few folks (me included) see putting time zone information in an environment variable with a new name (such as TIMEZONE) as a good thing. Doing so could avoid problems for "old" programs run with something such as TZ=US/Eastern or TZ=QST-3:15:25QDT-2:25:12;281/02:00:00,315/01:00:00 in their environments. Most folks on this mailing list, though, think it best to stick with TZ. It's an environment variable whose purpose is already clearly understood as being a repository of time zone information, and it would be a nuisance to have both it and TIMEZONE. So: I'll stick with using TZ (and will also hope that someone can come up with an explanation for doing so that's both brief and more compelling that the one in this paragraph). 2. As to how TZ should be initialized--I'd hope that the standard(s) will end up providing a scheme that doesn't require TZ to be initialized at all, and that if TZ is absent from the environment then programs will deliver "the best available approximation to local wall clock time." In a scheme where time zone information is kept in files, this is easy: you just, for example, do a ln /etc/zoneinfo/US/Eastern /etc/zoneinfo/localtime or ln /etc/zoneinfo/Moon/Darkside /etc/zoneinfo/localtime and set up the time handling functions to load things from "/etc/zoneinfo/localtime" if TZ is absent from the environment. As others have shown, in a "non-file" scheme it's also possible to cope with the absence of TZ--although more code is needed for coping purposes (since you need to both know the name of the file to be used and need to interpret its contents). Either way, I think that the time zone functions are the right place to handle dealing with what local time is-- and that init is the wrong place. 3. Folks have now outlined three ways for programs to ask for variant time zones: a. The "ctime.least" method outlined in some of Ron Tolley's manual pages, in which "localtime" simply examines the TZ environment variable each time localtime is called. To get a variant time zone, you just set up TZ with the variant before calling localtime (either directly or indirectly via ctime). b. The System V Release 2.0 method, in which you must set up the environment variable TZ and then call the function "tzset" to get stuff read out of TZ for future use by localtime. c. The settz("whatever") approach, in which an explicit call is provided for switching to a variant time zone, with no fiddling of the environment required. These days, I favor standardizing the second approach. If the first approach is standardized, I think there'll be too much code written along these lines: putenv("TZ", "whatever"); printf("%s", ctime(&t)); that won't do what's expected when it's moved to System V Release 2.0 systems. Yes, requiring the "tzset" call after the "putenv" *is* a nuisance--but better a nuisance than worng results. And: while I'd favor having the standard(s) specify that local wall clock time should be used if TZ is absent from the environment, I think we'd best recognize that existing systems *don't* do so. For those applications that *must* have local wall clock time, I'd provide a standard function "tzsetwall" (the name is subject to change) that sets things up to use the best available approximation of local wall clock time regardless of what's in the environment (with a tip of the hat to Guy Harris for pointing out that this is the easy way to handle things). So: if you only *wanted* local wall clock time, you could use the code: { char ** savedenv; extern char ** environ; static char * fake[1]; savedenv = environ; environ = fake; tzset(); environ = savedenv; } and end up with code that would compile on any UNIX system and would deliver local wall clock time on any POSIX system. If, on the other hand, you *needed* local wall clock time, you would use the code: tzsetwall(); which would deliver local wall clock time on any POSIX system, and wouldn't compile at all on any existing UNIX system. Yes, you wouldn't get any results at all--but not gettting any results is better than getting worng results. --ado .TH CTIME 3 .SH NAME ctime, localtime, gmtime, asctime, tzset, tzsetwall \- convert date and time to ASCII .SH SYNOPSIS .nf .B extern char *tzname[2]; .PP .B void tzset() .PP .B void tzsetwall() .PP .B char *ctime(clock) .B long *clock; .PP .B #include <time.h> .PP .B char *asctime(tm) .B struct tm *tm; .PP .B struct tm *localtime(clock) .B long *clock; .PP .B struct tm *gmtime(clock) .B long *clock; .fi .SH DESCRIPTION .I Tzset uses the value of the environment variable .B TZ to set time conversion information used by .IR localtime . If .B TZ does not appear in the environment, the best available approximation to local wall clock time is used by .IR localtime . .if !\nX \{\ If .B TZ does appear in the environment, .I localtime will only work correctly if its value is one of an implementation-defined set of values.\} .el \{\ If the value of .B TZ begins with a slash, it is used as the absolute pathname of the .IR tzfile (5)-format file from which to read the time conversion information; if .I zonename begins with some other character, it is used as a pathname relative to a system time conversion information directory. \} .PP .I Tzsetwall sets things up so that .I localtime returns the best available approximation of local wall clock time. .PP .I Ctime\^ converts a long integer, pointed to by .IR clock , representing the time in seconds since 00:00:00 GMT, January 1, 1970, and returns a pointer to a 26-character string of the form .br .ce Thu Nov 24 18:22:48 1986\\n\\0 .br All the fields have constant width. .PP .IR Localtime\^ and .I gmtime\^ return pointers to ``tm'' structures, described below. .I Localtime\^ corrects for the time zone and any time zone adjustments (Daylight Savings time in the U.S.A.); before doing so, .I localtime\^ calls .I tzset\^ if .I tzset\^ has not been called in the current process. After filling in the ``tm'' structure, .I localtime sets the .BR tm_isdst 'th element of .B tzname to a pointer to an ASCII string that's the time zone abbreviation to be used with .IR localtime 's return value. .PP .I Gmtime\^ converts to Greenwich Mean Time (GMT). .PP .I Asctime\^ converts a time value contained in a ``tm'' structure to a 26-character string, as shown in the above example, and returns a pointer to the string. .PP Declarations of all the functions and externals, and the ``tm'' structure, are in the .B <time.h>\^ header file. The structure declaration is: .RS .PP .nf struct tm { int tm_sec; /\(** seconds (0 - 59) \(**/ int tm_min; /\(** minutes (0 - 59) \(**/ int tm_hour; /\(** hours (0 - 23) \(**/ int tm_mday; /\(** day of month (1 - 31) \(**/ int tm_mon; /\(** month of year (0 - 11) \(**/ int tm_year; /\(** year \- 1900 \(**/ int tm_wday; /\(** day of week (Sunday = 0) \(**/ int tm_yday; /\(** day of year (0 - 365) \(**/ int tm_isdst; /\(** is DST in effect? \(**/ }; .fi .RE .PP .I Tm_isdst\^ is non-zero if a time zone adjustment such as Daylight Savings time is in effect. .SH SEE ALSO .if \nX tzfile(5), getenv(3), time(2) .SH BUGS The return values point to static data whose content is overwritten by each call. .. @(#)newctime.3 2.9

1 0

mod.std.unix announcement?
by ado Dec. 16, 1986

Dec. 16, 1986

If there's no objection, I'd like to announce the existence of the time zone mailing list in a mod.std.unix article. Let me know if there are problems; if not, I plan to submit an article this Thursday or Friday. --ado

1 0

Parsing /etc/TIMEZONE
by seismo!cuuxb!dlm Dec. 15, 1986

Dec. 15, 1986

I wrote a simpler and better parse of /etc/TIMEZONE. Also note that since /etc/init already does so one could steal its code. He is my short parse. Note, it does parse System V Release 3.1 versions which have OTHER lines of garbage (comments and such): === #include <stdio.h> #include <string.h> char def_timezone[] = "GMT0"; char * gettz() { FILE * tzfp; register char *bp; register char *tbp; static char buf[132]; if ( (tzfp = fopen("/etc/TIMEZONE", "r") ) == NULL) { return(def_timezone); } while ( fgets(buf, sizeof buf, tzfp) != NULL ) { if ( buf[0] == '#' || buf[0] == '\n' ) continue; buf[strlen(buf)-1] = '\0'; /* strip newline */ if ( strchr(buf, '=') == NULL ) continue; for (tbp = buf; ; ) { bp = strtok(tbp, "; \t"); if ( bp == NULL ) break; /* should be xx=xxx; */ if ( strchr(bp, '=') != NULL && strncmp( bp, "TZ=",3) == 0 ) break; tbp = NULL; } fclose(tzfp); return(strchr(bp,'=')+1); } fclose(tzfp); return(def_timezone); } ===== Note that we use the stdio AND SysV string functions. -- =Dennis L. Mumaugh Lisle, IL ...!{ihnp4,cbosgd,lll-crg}!cuuxb!dlm

1 0

Re: ATT System V Rlease 3.1 and Timezones
by seismo!sun!guy Dec. 13, 1986

Dec. 13, 1986

> 2. Init (/etc/init == process 1) reads and parses this file and > sets the environment of all children processes with the TZ > variable... There is no guarentee that some fiend doesn't step on the value before passing it to someone else. Even if there are no fiends, there may be remote users. One needs a mechanism to find out the correct timezone information from an unimpeachable source. "Source'ing" /etc/timezone is not slick if your process isn't the Bourne/Korn shell. True, but assuming that "/etc/TIMEZONE" has the format TZ=<name> that file can easily be parsed by a program other than a shell. (Nothing more is needed in "/etc/TIMEZONE"; e.g., if you want to export "TZ" after fetching it from "/etc/TIMEZONE", you just do "export TZ" after sourcing "/etc/TIMEZONE". Given that, if the argument to "settz" were "(char *)NULL", "settz" could fetch the machine's local time zone by doing something like register int fd; static char tzbuf[SIZE + 1]; register int i; fd = open("/etc/timezone, O_RDONLY); if ((i = read(fd, tzbuf, SIZE + 1)) < 0) return (-1); /* * The "SIZE + 1" is a hack to detect overly-long files. * We advertise SIZE as the maximum size, and if there's anything * after it, we complain. */ if (i == SIZE + 1) return (-1); if (i < 4) return (-1); /* doesn't start with "TZ=" */ if (strncmp(tzbuf, "TZ=", 3) != 0) return (-1); /* doesn't start with "TZ=" */ if (tzload(tzbuf + 3, &s) == -1) return (-1);

1 0

Re: ATT System V Rlease 3.1 and Timezones
by seismo!nbires!vianet!devine Dec. 13, 1986

Dec. 13, 1986

My, this proposal sounds familiar :-). I've since been won over to the stick-the-stuff-in-a-file-and-use-functions party. > 2. Init (/etc/init == process 1) reads and parses this file and > sets the environment of all children processes with the TZ variable... There is no guarentee that some fiend doesn't step on the value before passing it to someone else. Even if there are no fiends, there may be remote users. One needs a mechanism to find out the correct timezone information from an unimpeachable source. "Source'ing" /etc/timezone is not slick if your process isn't the Bourne/Korn shell. > 3. The TZ variable has new syntax and fields. First as sample > TZ=QST-3:15:25QDT-2:25:12;281/02:00:00,315/01:00:00 > Comments: > The new syntax for TZ allows for any time zone rule, but only > allows ONE change per year. The varialbe must be modified and > reset for the year being printed. Thus is TZ is set for 1987 a > full ctime for a previous year will result in odd information for > a few days each spring and fall (US). This goes to the heart of the proposal. I tried hard to convince myself that one year's definition suffices. However, it is certainly possible to do multiple years and to hide the nastiness as well by using a collection of files. When I proposed a redefinition of TZ to hold more info, it was in part because I didn't want to break UNIX conventions. I guess that is one of the underlying concern in this proposal too. Unfortunately they were always broken with respect to correctly handling the world's variety of timezones. Bob Devine

1 0

Re: ATT System V Rlease 3.1 and Timezones
by seismo!sun!guy Dec. 12, 1986

Dec. 12, 1986

1. The TZ environment is set and maintained in the file /etc/TIMEZONE and is a Bourne shell file that can be sourced ( . /etc/TIMEZONE) by any one who wishes. You'd better make that "can be source by any *Bourne shell* that wishes". There is no guarantee whatosever that a given user will ever have a Bourne shell running in their session; e.g., "uucp" usually has "uucico" as its login shell. "uucico" would have to read "/etc/TIMEZONE" itself, and pass the first line in that file to "putenv" after stripping off the trailing newline (remember, you do NOT want to permit the user to do TZ=EST5EDT uucp ... in order to force "uucico" to think it's after 11PM and thus force it to make the call to the target system immediately). 3. The TZ variable has new syntax and fields. First as sample TZ=QST-3:15:25QDT-2:25:12;281/02:00:00,315/01:00:00 This is totally wrong. For one thing, as you point out later, it makes the incorrect assumption that only the rules for the current year are of interest. For another, it sets TZ to a complicated string which also requires work to generate; how many of you who don't happen to have calendars that give Julian dates on every day page want to go through the trouble of figuring Julian dates out? (This is also a botch in the S5 accounting routines; you have to provide the Julian date of all the days to be considered holidays. A computer can figure that out much better than a human can.) Both Arthur Olson's and HP's schemes, which put the rules into a file and which just provide the *name* of the file to fetch them from, are vastly superior. Olson's code includes a compiler that makes generating the rules quite easy. 5. A new sequences of time functions [setcftime,ascftime,cftime] Oh boy, just what we need, a *third* set of functions, different both from ANSI C and from the HP-X/Open ones! AT&T-IS should either drop these functions in favor of one of the existing ones or get one or the other or both bodies to adopt theirs. 6. A variable LANGUAGE is used to specifiy the language of the output [default is ENGLISH with /lib/cftime/usa_english ] the default file. Files in /lib/cftime specify the default names and abbreviations of the days and months, as well as default strings for date and cftime (Europeans use dd/mm/yy and USA uses mm/dd/yy) and such. HP's scheme, at least as presented in the X/Open stuff I saw, is much better. Instead of a set of files specific to time formatting, they provide a general "string catalog", so that you can fetch messages, time and date format strings, etc. for the particular language and cultural environment. Having a "/lib/cftime" directory is just a hack. (Also, what does the LANGUAGE variable contain? For the US, would it be ENGLISH or "usa_english"? The former is incorrect; I believe the date format in Britain, for example, is different from that in the US, so just stating the language is insufficient.) 7. The environment variable CFTIME can be used to specify the default format string for cftime related functions and programs -- date now uses cftime. Why is this necessary, if there is a LANGUAGE variable? Comments: The new syntax for TZ allows for any time zone rule, but only allows ONE change per year. The varialbe must be modified and reset for the year being printed. Thus is TZ is set for 1987 a full ctime for a previous year will result in odd information for a few days each spring and fall (US). It also doesn't look like it can handle things like South Australia's switch from CST to EST. It seems like a trivial change to store a table of TZ variables for each year. I hope by "store a table" you mean "store a table *in a file*". This table could get pretty big if you really want it to specify the rules for the entire range of valid UNIX times. All in all, none of this is very good. Others have done it much better; AT&T-IS would be best advised to leave this *all* out of the SVID, and be prepared to do it differently in future releases.

1 0

ATT System V Rlease 3.1 and Timezones
by seismo!cuuxb!dlm Dec. 11, 1986

Dec. 11, 1986

The P.55 Timezone Proposal has been sent to a low level developer at ATT Summit, NJ. The current reading is that due to schedule pressures there is little likely-hood of anything being adopted by ATT unless it is part of ANSI C for the next year or so. It also appears that none of the subscribers to the mailing list are aware of changes and directions for recent releases of ATT software so here is a summary: 1. The TZ environment is set and maintained in the file /etc/TIMEZONE and is a Bourne shell file that can be sourced ( . /etc/TIMEZONE) by any one who wishes. 2. Init (/etc/init == process 1) reads and parses this file and sets the environment of all children processes with the TZ variable. It is thus propagated through cron, login and su. [And thus to csh (just for Mark :-) ]. (Feature in System V Release 3.1 and following). 3. The TZ variable has new syntax and fields. First as sample TZ=QST-3:15:25QDT-2:25:12;281/02:00:00,315/01:00:00 This says the offset from GMT is 3 hours 15 minutes and 23 seconds; Alternate time starts on Julian day 281 at 2am and reverts on Julian Day 315 at 1am. Alternate time is offset from GMT by 2 hours 25 minutes and 12 seconds. Note negative time offsets are East of Greenwich and thus -5:00 ougt to be somewhere in Russia. An example of a Southern Hemishpere setting for perhaps the Cook Islands (not to be considered a real thing, just a cooked example (no pun): TZ=KDT9:30KST10:00;64/5:00,303/20:00 For TZ strings with no time specified for the change (Julian date only) the change of time defaults to midnight local time. 4. If no TZ variable is set or exists default timezone rules are for GMT. 5. A new sequences of time functions [setcftime,ascftime,cftime] allow variable formats for time (similar in concept for the funny formats for date). int cftime(buf, fmt, clock) char *buf, *fmt; time_t clock; 6. A variable LANGUAGE is used to specifiy the language of the output [default is ENGLISH with /lib/cftime/usa_english ] the default file. Files in /lib/cftime specify the default names and abbreviations of the days and months, as well as default strings for date and cftime (Europeans use dd/mm/yy and USA uses mm/dd/yy) and such. 7. The environment variable CFTIME can be used to specify the default format string for cftime related functions and programs -- date now uses cftime. Comments: The new syntax for TZ allows for any time zone rule, but only allows ONE change per year. The varialbe must be modified and reset for the year being printed. Thus is TZ is set for 1987 a full ctime for a previous year will result in odd information for a few days each spring and fall (US). It seems like a trivial change to store a table of TZ variables for each year. The cftime additions are useful for international situations but still the TZ rules are a bit parochial. -- =Dennis L. Mumaugh Lisle, IL ...!{ihnp4,cbosgd,lll-crg}!cuuxb!dlm

1 0

Re: TZ, ZONE, TIMEZONE, settz(), ... ?
by Chris Torek Dec. 11, 1986

Dec. 11, 1986

I agree with kre: The original design was wonderful. The major problem was that it was not---quite---compatible with 4BSD and with SysV. Yet the incompatibilities were in areas that everyone agrees were weak, and, moreover, in areas that were mutually incompatible anyway! Any new standard *must* break some code. Let it break code that was acknowledged insufficent, and by replacing it with code that has been tested and found satisfactory. Chris

1 0

comments of proposals
by seismo!nbires!vianet!devine Dec. 11, 1986

Dec. 11, 1986

Excuse the delay in responding to some of the issues, things have been rather hectic. Some mail may have been dropped locally (sorry if I'm talking about something that is solved). 1. Ctime functions. I favor the following small collection: char* ctime(time_t) struct tm* localtime(time_t) struct tm* gmtime(time_t) char* asctime(struct tm*) time_t mktime(struct tm*) int settz(char*) /* set up a user selectable timezone */ int strftime(char*, int, char*, struct tm*) These supply the time conversion capabilities needed. This set can be extended with internationalization functions that parallel ctime() and asctime(). "Maybe" category: int strfastime(char*, int, char*, struct tm*) int systz() -- 1) set up the system default timezone -- 2) not needed if a certain string passed -- to settz() tells it to use the local -- system timezone (settz("LOCAL") ? ) -- (internationalization problems?) int yearlength(int, int) [see comment below] Not included are: long timezone; /* yuck */ int daylight; /* yuck */ int dysize(int) [see comment below] char* tzname[2] /* too limited */ timezone() zonetime() -- I haven't seen the definition of this HP's nl_*() functions I have submitted a group of functions to Rich Salz for posting to mod.sources that, while not yet complete, do deal with the many different country-dependent changes to calendars. It is a function that takes a Christian era year and a country id and returns the number of days in that year for that country. yearlength() is more thorough that dysize(). The function's current drawbacks are that some of the dates are a bit shaky (I have on order a book from the Vatican that I was told is the definitive source) and not all countries from all years are represented. 2. Modification to 'struct tm'. I agree that 'struct tm' should be modified to adequately describe a certain time. So, three fields should be added: struct tm { /* all current fields */ time_t tm_tzdiff; time_t tm_dstdiff; char* tm_tzname; }; The elements 'tm_tzdiff' and 'tm_dstdiff' are for informational and, more importantly, for the mktime() function so that it can correctly convert any 'struct tm' into a time_t. Both are set to the time_t equivalent of zero for the structure filled in by gmtime(). 'tm_tzdiff' holds the difference in seconds (or whatever time_t is defined to hold) for the timezone difference from UTC. 'tm_dstdiff' is the same but for daylight saving time (is there a better name that describes the seasonal clock changes? [see note]). The 'tm_tzname' is the name of the timezone used when filling in the structure. Its role is informational and also serves as a guide to going from 'struct tm' to a time_t. [note: the city of Denver looked at the possibility of going to a clock change for the high-pollution period of December-February where temperature inversion and reduced auto efficiency in cold weather result in very high carbon monoxide levels. Changing the clocks so that Denver would, in effect, be in Central Time instead of Mountain Time would help reduce the levels because the sunlight would alleviate some. Consider this a LST - lung saving time :-)] 3. TZ and TIMEZONE For current programs that use it, TZ must be kept as is. The new variable TIMEZONE should be defined to handle the wide range of possible and different timezones that TZ can't handle. Its format could be open or tightly defined; I haven't given this enough thought. Bob Devine [ in case you're interested in what caused the havoc around here, no, the entire place is not shutting down as happened to me at UNISYS (nee Burroughs). ViaNetix just got sold to a company whose name I can't yet give out and we changed what machine is known as 'vianet'.]

1 0

Re: timezone proposals for P1003
by seismo!zotz.cs.utexas.edu!jsq Dec. 9, 1986

Dec. 9, 1986

The current state of timezones in P1003 is that there is a proposal, P.55, which is one step past the prevrious form, RFC.001. You've seen the text for oboth on mod.std.unix. I haven't yet attempted to get P.55 adopted as part of the actual document. This is because a) I'm stilll waiting for HP to produce their long-awaited alternative proposal and b) I'm stuck in L.A. and won't be at the meeting this week. Simplicity has been stresssed in discussing timezones in P1003 meetins. Members have seen your (and others') previous omments. I expect to get the committee to consider actually adopting P.55 at the next meeting in March. There has been no noticable objection from the AT&T reps or anyone, really, thus far, except that HP want their proposal instead (though no one has seen it yet). I would strongly recommend that any needed changes to P.55 be gotten to me before March and any points I don't know about tha should be raised in discussion be relayed.

1 0

Conversation with Ron Tolley
by ado Dec. 9, 1986

Dec. 9, 1986

Ron Tolley of Hewlett-Packard called Friday. I'd like to relay a couple of points Ron made (points which may or may not reflect official corporate policy of H-P, blah blah blah), add some notes of my own (notes which may or may not reflect official policy of the National Institutes of Health, blah blah blah), and ask for comments. 1. Setting up "new" time zone handling software to deal with environment variables such as TZ=US/Eastern may make for problems when running "old" executables that expect the TZ environment variable to be of the form TZ=EST5EDT where, depending on the quality of an implementation, "problems" here can range anywhere from getting core dumps to getting incorrect results. As others have noted, staying strictly with the current System V TZ=<standard abbreviation><offset from GMT><daylight abbreviation> system can't work--for example, with TZ=EST5EDT there'd be no way to tell whether a user wanted Canadian or US Daylight Saving Time rules applied. The possibilities I see: a. Continue to demand that the TZ environment variable be of the form TZ=<standard abbreviation><offset from GMT><daylight abbreviation> (a possibility I'd dislike). b. Set things up so that, for example TZ=EST5EDT asks for US rules to be used while TZ=Est5Edt asks for Canadian rules to be used--although either of the above would "EDT" to be used in the output of date(1) and such. This will, of course, meet with the disapproval of those who think case sensitivity in UNIX is a bad thing. :-) c. Set things up so that the TZ environment variable is of the form TZ=EST5EDT and so that a new environment variable such as TZTYPE=Canada tells the type of time zone rule to be applied. d. Set things up so that instead of setting TZ=US/Eastern you instead use some new environment variable--for example ZONE=US/Eastern With this approach, old executables don't get confused by zone information that's in a new format since the new-format information is put in a place that the old executables don't look. The disadvantage of this approach is that old executables don't get *any* information about what the user wants. (Implementation point: new software would presumably first look for "ZONE" in the environment and then fall back on "TZ" if "ZONE" was absent from the environment.) e. Throw caution to the wind and set things up so that TZ=US/Eastern is used (a possibility that Ron Tolley dislikes). My current leaning would be toward possibility 'd' above--with careful documentation of tzset's habit of looking for ZONE and then TZ. 2. Ron noted that H-P's approach to getting guaranteed local wall clock time is to use the 4.?BSD "gettimeofday" call. This contrasts with approach demanding that local wall clock time be returned by "localtime" if there's no TZ environment variable. The H-P approach does have a real backward-compatability advantage. If, in trying to ensure that I'm going to get wall clock time, I write code that zaps TZ from the environment and then does tzset(); and localtime(); calls, the code will happily compile and run on existing System V systems-- and may give wrong results. If, on the other hand, I write code that calls gettimeofday(); the code won't compile at all on existing System V systems. The bad news is that I won't get any results at all; the good news is that I won't get wrong results. One possibility I'd see: drop the demand that local wall clock time be used if TZ is absent from the environment, and add a function such as walltime() that returns "the best available approximation of local wall clock time regardless of the setting of the TZ environment variable." It would be a close analog of "gmtime". --ado

2 1

Re: walltime vs localtzset
by ado Dec. 8, 1986

Dec. 8, 1986

Guy Harris's point on localtzset being much easier to implement than walltime is very well taken. Of course, the real name will need to be different to avoid conflicts between localtime and localtzset on systems with only six characters worth of external identifiers. Maybe tzsetlocal? --ado

1 0

Re: Conversation with Ron Tolley
by seismo!sun!guy Dec. 8, 1986

Dec. 8, 1986

...instead use some new environment variable--for example ZONE=US/Eastern With this approach, old executables don't get confused by zone information that's in a new format since the new-format information is put in a place that the old executables don't look. The disadvantage of this approach is that old executables don't get *any* information about what the user wants. Old executables can't necessarily give the user what they want anyway; for example, they won't give people in South Australia what they presumably want. (Implementation point: new software would presumably first look for "ZONE" in the environment and then fall back on "TZ" if "ZONE" was absent from the environment.) If "TZ" is to be parsed, rather than used as a file name, you'd have to indicate which rules are used; presumably, you can use the US rules (i.e., hardcode the current rules, or the current rules as modified for the 1987 change), since that leaves people no worse off than they are now. Also, I'd vote to change "ZONE" to "TIMEZONE"; environment variables don't need to have short names, and you might as well give them a name that more precisely explains what they do. One minor nuisance with this is that a program would have to smash both "ZONE" and "TZ" in order to guarantee that they'll get the CPU's local time (we ignore the possibility of the CPU being in one time zone and the modems, or the bulk of the terminals, being in another :-)). If, on the other hand, I write code that calls gettimeofday(); the code won't compile at all on existing System V systems. Did they really mean programs call "gettimeofday" directly? All "gettimeofday" returns is the current UNIX clock time (which is in GMT/UTC) and, optionally, a structure indicating the current offset from GMT and rule set to be used to handle DST. As such, you'd have to duplicate much of "localtime" to use this data, which seems excessive, and it would still suffer from the disadvantages of the 4BSD scheme. One possibility I'd see: drop the demand that local wall clock time be used if TZ is absent from the environment, No! It is difficult, if not impossible, to guarantee that TZ will be properly set in the environment. Forcing every use to stick something in their ".profile" or ".login" is gross, and also doesn't work if your login shell is neither "/bin/sh" nor "/bin/csh". This would screw not only login "shells" like "/usr/lib/uucp/uucico" (although it doesn't *want* TZ to be set, it always wants the machine's local time) but also things like office automation systems and other applications that put you into a special environment when you log in. Those applications don't necessarily know anything about shell scripts, so they can't just scan ".profile" or "/etc/profile" or whatever. and add a function such as walltime() that returns "the best available approximation of local wall clock time regardless of the setting of the TZ environment variable." It would be a close analog of "gmtime". This is a bit complicated; I'd prefer something like localtzset() which acts like "tzset()" except that it looks neither at "TZ" nor at "TIMEZONE" but forcibly sets things up for the "official" local time zone of the machine. That minimizes the changes needed to fix things like "uucico". This also obviates the need for an application to smash both "TZ" and "TIMEZONE" if it wants local time; "localtzset()" would do whatever is necessary, and the application wouldn't have to know what was necessary. The rules would be: "localtzset()" would forcibly cause subsequent conversions to use local time. "tzset()", called by "localtime" and "mktime" would first check if "TIMEZONE" was present in the environment; if so, it would use that. Otherwise, it would check if "TZ" was present in the environment; if so, it would use that. Otherwise, it would use local time. "TZ" looks like it would be a wart if it were put into the P1003 standard (as opposed to a UNIX manual page, where people are used to seeing horribly warty specifications). However, if you leave it out, it would either have to say that if "TIMEZONE" isn't set, it uses local time (if possible), meaning that "TZ" can't affect its behavior, or would have to say that the behavior if "TIMEZONE" is not set is implementation-dependent, meaning that the current unacceptable S5 behavior (use Eastern Standard Time if "TZ" isn't set) would be permitted.

1 0

Re: Conversation with Ron Tolley
by seismo!cbpavo.MIS.OH.ATT.COM!mark Dec. 8, 1986

Dec. 8, 1986

I also think going to a new environment variable such as ZONE (I'd rather see it called TIMEZONE) is the best choice; there's nothing to prevent the system from defining both TZ (for upward compatbility) and TIMEZONE (for new software which checks for it first.) I think that any standard that requires that TZ do anything may be a mistake; if the standard says that a missing TZ means something, then any upward compatible future standard based on another variable will lose big. It would be best if comments about what to do if TZ is missing were made in such a way that they are just a fallback, not a way for a program to get a guaranteed behavior. Mark

1 0

Re: timezone proposals for P1003
by seismo!cbpavo.MIS.OH.ATT.COM!mark Dec. 8, 1986

Dec. 8, 1986

Just a brief note on history; Robert points out, quite correctly, that the 4BSD timezone() function, use of ftime, and so on, all date back to V7. I just wanted to point out that the System V convention of the external variables "timezone" and "daylight" date back to V6, essentially untouched. V6 did not have ftime, the TZ environment variable (or environments at all), nor tzset. I'm not sure how it knew the local time zone; I don't believe the date command, or any other piece of software, produced a time zone name, but I think timezone and daylight were statically compiled into libc, and you had to relink the system if you installed it anywhere except the USA Eastern zone. Thus, the conflict between the timezone external integer, and the timezone function, seems to have been introduced by Bell Labs 127 group, sometime between V6 and V7. This conflict will make life interesting for any implementations striving for upward compatiblity with both systems. As far as I am able to determine, neither X3J11 nor POSIX requires either, but of course the SVID requires the integer. This suggests that it would be nice if Berkeley phased out the function. Mark

2 1

timezone proposals for P1003
by Robert Elz Dec. 7, 1986

Dec. 7, 1986

I think things are getting way too complicated. All P1003 needs (and all it should have) is a spec of the interface that programs should have to time conversions. And that ought to be the minimally sufficient set, not everything that might be useful to someone, someday. nb: this is not a reference to the "nl" procedures, some kind of standard for that is clearly needed, or posix will be tied to English (or what passes for English in the US) forever. What I am referring to is the file formats, etc, which clearly don't need to be in any standard. What's more, there should not even be an implication that there is a file with this kind of information in it somewhere. That's none of the interface's business, its an implementation issue. On a host with good shared libraries, continuing to compile the needed information into libc.a is a perfectly reasonable strategy. Another would be to make a RPC call to some server to obtain the information. P1003 has no business outlawing any of that. Furthermore, there is NO need for P1003 to contain everything that's in Sys V. Not even AT&T believe that. Unless some detail of Sys V is needed for the interface, then it should not be there (this does not make P1003 incompatible with Sys V, it just makes Sys V a superset, offering more than P1003 requires). In this area Sys V's "timezone" and "daylight" variables fall. They're next to useless, a static variable in the Sys V sense cannot possibly contain useful information. if they were allowed to change on each call to localtime, to reflect the results of that call they might be useful, but without that they're useless. I've never yet seen an application with any excuse for using "daylight". The information purported to be supplied in "timezone" does have its uses, but the static variable can't contain that. What do you think should be in "timezone" in South Australia, where the standard zone is currently 9:30 ahead of GMT, but which is going to change to 10:00 ahead of GMT on Mar 15 (I think) next year? Should "timezone" be -36000 or -34200? Remember that there will be application programs running at the instant this switch is made (02:00 standard time, on that morning), so any solution that involves changing the value of timezone (a variable that isn't altered after its set by tzset()) can't be correct. For "timezone" in the Sys V sense to be meaningful at all, one of those two numbers (or perhaps some other) must be chosen, and retained forever. The v7 (inherited by bsd) "timezone()" function is a joke. It can't even come close to doing what it claims. It has to go. Incidentally, all the "bsd" columns here should be labelled "v7". Bsd has made no changes to any of this, at all, ever. All that ever changed in this area was some of the implementation details. Also, there's no good reason for the standard to constrain the syntax of the TZ environment variable in any way at all. If some implementation finds that it can extract useful information from the letters, digits, colons, etc, found in the value of that variable, then fine. That is perfectly consistent with an unconstrained format. But, as soon as you introduce any unnecessary rules, things start breaking down. As an example, last year, the TZ values (in the standard Sys V sense) for NSW and Victoria (in Australia) would have been identical. Both EST-10EST. (That is, both NSW and Vic have "EST" as their timezone abbreviation in standard time (Eastern Standard Time, as in the US), they're both 10 hours ahead of GMT, they both have daylight saving, and both use EST as the abbreviation for the zone name when daylight saving is used (Eastern Summer Time). But last year (for a week) their daylight saving rules were different. The Sys V format simply cannot cope with this kind of thing. (I think they were different last October, if not then, they were in 1982 for 3 weeks in March). The unconstrained form can handle this. Easily. So, please, in any submissions to P1003 (on this point, and any others) please emphasise simplicity. Anything that's not demonstrably both essential, and workable, should be omitted. What MUST be there is some way for a program to get access to localtime in the absense of a TZ variable. There are security issues here, TZ is a user alterable variable, and cannot be depended upon. This is the one thing that is going to have to be added to Sys V. Add that, and current Sys V should be P1003 compliant (ignoring language issues for now). BSD is going to need more changes, but that's not a problem, changing BSD is easy... Personally, I don't much like the idea of doing that by having the TZ variable changed by the application. That would be workable, certainly (assuming that there was some guaranteed value it could be set to to obtain local time) but it seems more complex than is needed, and somehow just not nearly as clean as settz((char *)0) in ado's current code. Also, given that this is absolutely essential (and this is THE defect in the Sys V current localtime interface incidentally - that it has one set of daylight saving rules compiled in is a mere implementation foible -- oh yes, the "only hours" in the TZ variable is another defect) its a good idea to make the default be that if there's no TZ variable, then localtime is obtained. That means that users who only want localtime anyway need one less environment variable slowing down all their processes - the environment should be used for user configuration, not system configuration. I'm not much thrilled with tzname[2] either. To be truly Sys V compat, that also needs to be statically set at the tzset() - a Sys V process can now grab pointers to the strings in tzname after tzset() and use those forever after. There's no way to be compatible with that, and at the same time handle a location with more than 2 zone names. Again, South Australia next year, it will have CST, EST and EST all in the same year. (That two of these are the same is a coincidence, assume for now that Australia used the US naming convention, then the names would be CDT EST and EDT). I gather that the current idea is to make tzname[] be a placeholder for a result of localtime(), changing after each call. I'm not sure what the "other" size of tzname[] is supposed to contain though. Ie: if I reference tzname[!tp->tm_isdst] what do I get? Is it always defined? How? Looks impossible to me (that is, to be defined to something sensible). This looks to be another area where the desire for Sys V compatibility is going wild. If its *wrong* in Sys V than POSIX is the chance to fix it. Possibly the last chance, forever. Perpetuating an error just for some compatibility seems like a bad idea. A better idea might be to add a "char *tm_zone" to "struct tm" and shove the zone name in there. That at least makes it quite clear that the zone name is a property of the specific time, and that a zone name without an associated time is a meaningless concept. Yes, I know this is going to break some programs, and that's a pity, but I think its necessary. Robert Elz seismo!munnari!kre ps: I have added a cc to John Quarterman, who I guess is as close as anyone to being my representative on P1003, given that I'm a usenix member... John, this is in response to some discussions over the HP proposals and other replated issues. elsie!ado can fill you in on what's been going on I think. There's a mailing list at elsie for tz discussions.

1 0

a letter from hpfcdg!rgt
by Arthur David Olson Dec. 4, 1986

Dec. 4, 1986

From seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt Thu Dec 4 08:57:02 1986 To: elsie!ado Subject: ctime proposal ado, Please feel free to circulate this to the ctime community. >Guy Harris has sent me corrections and additions to the latest versions of >the time zone stuff--and, in particular, has added some code to "newctime.c" >both for better System V compatibility and to provide the "mktemp" function >specified in recent versions of the X3J11 (a.k.a. C Standard) committee's >drafts. If you'd like to receive the new versions, let me know. mktemp is really mktime, I assume. >Here's a table summarizing the current state of agreement among various >existing and proposed sets of time-handling functions. One idea for >getting better agreement follow the table. I have added X3J11 and X/OPEN to the extent that I understand them. I have also restated HP to reflect what is currently implemented and available, not what I thought we might get from a compromise package. Variables and functions provided by. . . V.2 4.3 HP X3J11 X/OPEN ado guy ------------------------------------------------------------------------------ ctime() yes yes yes ?? yes yes yes localtime() yes yes yes ?? yes yes yes gmtime() yes yes yes ?? yes yes yes asctime() yes yes yes ?? yes yes yes long timezone yes no yes ?? yes no yes int daylight yes no yes ?? yes no yes char *tzname[2] yes no yes ?? yes yes yes tzset() yes no yes ?? yes yes yes timezone() no yes no ?? no no no (5) dysize(int y) no yes no ?? no no yes (1) nl_ctime no no yes ?? yes no no (4) nl_asctime no no yes ?? yes no no (4) nl_cxtime no no yes ?? yes no no (4) nl_ascxtime no no yes ?? yes no no (4) strftime no no no yes no no no (4) zonetime() no no no ?? no yes yes settz() no no no ?? no yes yes mktime() no no no yes no no yes (2) gmtime2() no no yes ?? no no yes (3) > (1) This undocumented Berkeley function returns 366 if its > (single integer) argument is divisible by four; it returns > 365 otherwise. This is not strictly correct for the Gregorian Era, although it is for 1970 to 2037 (or was that 190? to 2037) multiples of 100 should return 365 except multiples of 100 and 400 which should return 366. > (2) As described in recent X3J11 committee drafts, this > function ". . .converts the broken-down time, expressed > as local time, in the [struct tm] pointed to by [it's > argument] into a calendar time value with the same encoding > as that of the values returned by the time function." (3) gmtime2 is the inverse of gmtime, converting a time value in the tm structure into a calendar time value. Currently it is static and undocumented. (4) nl_ctime, nl_asctime, nl_cxtime, nl_ascxtime, and strftime all are designed add a) formatting capability and b) locale-specific month and day names. These 5 can easily be merged to one or two routines. For those who have not seen X3J11/86-125R by D. F. Prosser, strftime() is defined as: int strftime(str, n, format, tp) char *str; /* return string */ int n; /* maximum string length */ char *format; /* format string similar to date + */ struct tm *tp; /* time value structure */ (5) timezone() is not adequate for an international standard. It assumes that the time zone name (EST) or DST name (EDT) can be derived simply from the offset from GMT. >A way I see of getting better agreement is to eliminate "settz" and "zonetime". >The capabilities these functions provide can, for the most part, >be provided by direct manipulation of the environment variable TZ, >combined with "tzset" calls (assuming, of course, that good-enough functions >for environment manipulation are available.) >True, it means more work for programmers interested in changing time zones-- >but the need to do so is rare, and the extra work will pay off >since the results of the work will be somewhat more portable >(in particular, will be more portable to existing System V environments). >Any comments on the above idea? Any other ideas? May I suggest the following be done immediately: 1) From the subset above, I would like to suggest that we select the following: V.2 4.3 HP X3J11 X/OPEN ado guy ------------------------------------------------------------------- ctime() yes yes yes ?? yes yes yes localtime() yes yes yes ?? yes yes yes gmtime() yes yes yes ?? yes yes yes asctime() yes yes yes ?? yes yes yes long timezone yes no yes ?? yes no yes int daylight yes no yes ?? yes no yes char *tzname[2] yes no yes ?? yes yes yes tzset() yes no yes ?? yes yes yes dysize(int y) no yes no ?? no no yes strftime() no no no yes no no no strasftime() no no no no no no no gmtime2() no no yes ?? no no yes 2) Add long tm_tzadj to tm structure. It is incorrect to assume that one hour should be added or subtracted based on tm_isdst. For example, parts of Indiana are on CDT when tm_isdst is true and EST when tm_isdst is false. This will correctly indicate whether tzname[0] or tzname[1] should be used. However the actual offset from GMT does not change. This gives analogs to daylight and timezone external variables which are applicable to the time value contained in the tm structure. struct tm { int tm_sec; int tm_min; int tm_hour; int tm_mday; int tm_mon; int tm_year; int tm_wday; int tm_yday; int tm_isdst; long tm_tzadj; }; 3) Select gmtime2() over mktime() since it is a true inverse of gmtime(). The result of gmtime2() can trivially be modified to correct for local time using tm_tzadj mentioned above. 4) Define a strasftime() which is (as a parallel to ctime()): return(strftime(str, n, format, localtime(clock)); 5) Retain the System V Release 2 syntax for TZ. In addition, augment it to handle handle minutes such as TZ=CST-9:30CDT for for Queensland, Australia. 6) settz("value") may be approximated as putenv("TZ=value"); tzset() 7) Augment field descriptors for date(1) to parallel X3J11 strftime() proposal. In most cases strftime() uses date(1) descriptors. In the future we should also address: 8) Look at time() values beyond 1970 to 2037. P1003 has already done some work here. 9) Look at the difference between GMT and UTC (Universal Coordiated Time -- this is the correct name and correct abbreviation). I believe that GMT uses seconds of variable length to accommodate the inaccuracies of nature. UTC on the other hand uses leap seconds. It is UTC which is generally available from WWV and other international time standard sources. Ron Tolley

1 0

Another round from Hewlett-Packard
by Arthur David Olson Nov. 27, 1986

Nov. 27, 1986

Ron Tolley has sent me revisions of the Hewlett-Packard ctime and tzfile manual pages; anyone interested in receiving a copy of the revisions should let me know. --ado

1 0

seismo!elsie!tz ; new versions of time zone stuff
by ado Nov. 25, 1986

Nov. 25, 1986

Now that we've moved from 4.1BSD to 4.3BSD here at elsie, I've set things up so that mail sent to seismo!elsie!tz will go to folks who've expressed an interest in time zone matters. The address seismo!elsie!tz-requests may be used for administrative matters. Currently on the list: ado(a)elsie.UUCP chris(a)umcp-cs.UUCP mark(a)cbosgd.ATT.COM kre(a)munnari.OZ dlm(a)cuuxb.ATT.COM devine(a)vianet.UUCP bob(a)anvil.UUCP rgt(a)hpfcdg.UUCP guy(a)sun.UUCP If you want to be removed from the list, or know of someone to add to the list, let me know. ******************************************************************************* And now the real news: new versions of the time zone compiler, the ctime et al. library, and the time zone data are available. Guy Harris provided the bulk of the ideas and work that went into the new versions, but should be held innocent of any blame for errors since I've tinkered with Guy's work (in part to try for more compatibility with System V and the work of rgt(a)hpfcdg.UUCP, who's the time zone person at Hewlett-Packard). The important differences: * There's a new format for the binary versions of time zone information files, designed to allow the files to be used by both big-endian and little-endian machines in shared file environments. * Up to now, a call of "localtime" caused the global variable "tz_abbr" to be set to point to the time zone abbreviation that was appropriate for use with the converted time. Now, "localtime" stores the pointer in tzname[*localtime()->tm_isdt], which is where System V programs have expected to find it. * Also for System V compatability, the function tzset is provided-- it just does a settz(NULL). * And the compiler is now a bit smarter--if you feed it something like: # Zone NAME GMTOFF RULE/SAVE FORMAT [UNTIL] Zone US/Hawaii -10:30 USA H%sT 1933 Apr 30 2:00 -10:30 1:00 HDT 1933 May 1 2:00 -10:30 USA H%sT 1947 Jun 8 2:00 -10:00 - HST it will apply the normal USA rules in Hawaii until April 30, 1933, then do Hawaii's day's worth of daylight saving, then switch back to standard rules until June 8, 1947, and finally go on to permanent standard time thereafter. This does a lot to shorten (if not simplify) the compiler's input files. If you'd like copies of the new versions, let me know. Once the new stuff has made the rounds, I'm hoping to get the benefit of other perspectives on what more can be done to bring this work, Hewlett-Packard's work, System V, and BSD closer together. --ado

1 0