- tz - lists.iana.org

PD Localtime changes since v08i085?
by emoryu1!gatech!rutgers!datapg.mn.org!sewilco March 14, 1988

March 14, 1988

Were there any changes to the PD "localtime" since the version posted in mod.sources as v08i085 on 28 Feb 87? It's time to use it, and I need to know if there were bugs found. I don't see any updates in the archive listings. The only change which I found so far was changing the "pacificnew" entries from type "uspres" and "nonpres" to a single type "-" entry. According to the Department of Transportation, no version of the Presidential Election Time became law. Scot E. Wilcoxon sewilco(a)DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco Data Progress C and UNIX consulting +1 612-825-2607

1 0

time zone functions in January 11, 1988 draft C standard
by ado Feb. 17, 1988

Feb. 17, 1988

Little in the way of change to time functions in the January 11, 1988 draft C standard. Recall that the last draft said, in the main text, this about the tm_isdst element of the struct tm structure: The value of tm_isdst is positive if Daylight Saving Time is in effect, zero if Daylight Saving Time is not in effect, and negative if the information is not available. It later described the new "mktime" function for converting a struct tm back into a time_t value, noting in a footnote that A positive or zero value for tm_isdst causes the mktime function initially to presume that Daylight Saving Time, respectively, is or is not in effect for the specified time. A negative value for tm_isdst causes the mktime function to attempt to determine whether Daylight Saving Time is in effect for the specified time. Your correspondent sent a letter to the X3J11 committee, noting (among other things) that the above material was all well and good, but since it was in a footnote, \fIand since footnotes are not part of the Standard\fP, programmers would not be able to count on the above characteristics of mktime. Well, the good news is that X3J11 acted on this point. The other news is that they simply changed the footnote to read Thus, a positive or zero value for tm_isdst. . . This makes me realize just how feeble-minded I must be getting in my dotage. I didn't understand (and still don't understand) how the promise that "A negative value for tm_isdst causes [mktime] to attempt to determine whether [DST] is in effect. . ." is implied by the description of tm_isdst in the standard. (Actually, I'm unclear about both sentences in the footnote, but the second especially.) Maybe someone on the time zone mailing list will be able to set me clear before I again make a fool of myself in my next letter to the Committee? Other than the added "Thus," there were no time-related changes to section 4.12 of the draft. They did throw in a few "noalias"es and required that if you #include <time.h> then NULL and size_t will be defined for you. --ado

1 0

Help wanted in updating time zone information files
by ado Jan. 2, 1988

Jan. 2, 1988

I'm hoping to send some updated time zone information files to comp.sources.unix soon (as soon as I can learn the equation of time for 1988 and, with that information, do up the 1988 Riyadh table). I've attached a bundle of the new files that would be used in making the posting; I'd appreciate any corrections or additional information that folks might provide. Here's a summary of the changes these files reflect. Thanks to Guy Harris for providing the vast majority of the changes. * The "northamerica" file has information about Mexico and about DST being observed on Navajo lands within Arizona. * The "pacificnew" file has information on the status of H.R. 435 (the bill whose passage would necessitate use of the "pacificnew" stuff). * The "southamerica" file is completely new. * The "asia" file is almost completely new; it now covers both Chinas and the Republic of Korea. --ado : To unbundle, sh this file echo 'northamerica' 1>&2 cat >'northamerica' <<'End of northamerica' # @(#)northamerica 3.4 # US Daylight Saving Time ended on the last Sunday of *October* in 1974. # See, for example, the front page of the Saturday, October 26, 1974 # and Sunday, October 27, 1974 editions of the Washington Post. # Note also this from seismo!munnari!kre: # "I recall also being told by someone once that Canada didn't have # the DST variations in 74/75 that the US did, but I am not nearly # sure enough of this to add anything." # The above has been confirmed by Bob Devine; we'll go with it here. # Before the Uniform Time Act of 1966 took effect in 1967, observance of # Daylight Saving Time in the US was by local option, except during wartime. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule US 1918 1919 - Mar lastSun 2:00 1:00 D Rule US 1918 1919 - Oct lastSun 2:00 0 S Rule US 1942 only - Feb 9 2:00 1:00 W # War Rule US 1945 only - Sep 30 2:00 0 S Rule US 1967 max - Oct lastSun 2:00 0 S Rule US 1967 1973 - Apr lastSun 2:00 1:00 D Rule US 1974 only - Jan 6 2:00 1:00 D Rule US 1975 only - Feb 23 2:00 1:00 D Rule US 1976 1986 - Apr lastSun 2:00 1:00 D Rule US 1987 max - Apr Sun>=1 2:00 1:00 D ############################################################################### # New names # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone US/Eastern -5:00 US E%sT Zone US/Central -6:00 US C%sT Zone US/Mountain -7:00 US M%sT Zone US/Pacific -8:00 US P%sT Zone US/Yukon -9:00 US Y%sT # Mainland US areas that are always Standard as of 1986. Zone US/East-Indiana -5:00 US E%sT 1946 -5:00 - EST # Always EST as of 1986 Zone US/Arizona -7:00 US M%sT 1946 -7:00 - MST # Always MST as of 1986 # However. . .a writer from the Inter Tribal Council of Arizona, Inc., # notes in private correspondence dated 12/28/87 that "Presently, only the # Navajo Nation participates in the Daylight Saving Time policy, due to its # large size and location in three states." Link US/Mountain Navajo # And then there's Hawaii. # DST was observed for one day in 1933; # Standard time was change by half an hour in 1947; # it's always standard as of 1986. Zone US/Hawaii -10:30 US H%sT 1933 Apr 30 2:00 -10:30 1:00 HDT 1933 May 1 2:00 -10:30 US H%sT 1947 Jun 8 2:00 -10:00 - HST # Old names, for S5 users # Link LINK-FROM LINK-TO Link US/Eastern EST5EDT Link US/Central CST6CDT Link US/Mountain MST7MDT Link US/Pacific PST8PDT Link US/East-Indiana EST Link US/Arizona MST Link US/Hawaii HST ################################################################################ # Canada is reportedly lots easier than the US--leastways since 1951. # I don't know what they did before then. # 4.3BSD claims that it's perfectly regular. # According to a posting in "comp.bugs.misc", "comp.unix.wizards", etc. # on February 8, 1987, by Dave Sherman of the Law Society of Upper Canada, # "...Canada (well, Ontario and at least some of the other provinces) are # adopting the new daylight savings time rules...". We assume all of # Canada is doing so. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Canada 1969 max - Oct lastSun 2:00 0 S Rule Canada 1969 1986 - Apr lastSun 2:00 1:00 D Rule Canada 1987 max - Apr Sun>=1 2:00 1:00 D # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] # Bob Devine says that DST *is* observed in Newfoundland Zone Canada/Newfoundland -3:30 Canada N%sT Zone Canada/Atlantic -4:00 Canada A%sT Zone Canada/Eastern -5:00 Canada E%sT Zone Canada/Central -6:00 Canada C%sT Zone Canada/East-Saskatchewan -6:00 - CST # No DST as of 1987 Zone Canada/Mountain -7:00 Canada M%sT Zone Canada/Pacific -8:00 Canada P%sT Zone Canada/Yukon -9:00 Canada Y%sT ################################################################################ # Mexico # Rules are from the Official Airline Guide, Worldwide Edition, for 1987. # Rules prior to 1987 are unknown. # The comments in the OAG say "Only Ensenada, Mexicale, San Felipe and Tijuana # observe DST." This is presumably Baja California Norte, above 28th parallel, # as listed there; Mexico/BajaSur is for "Baja California Sur and N. Pacific # Coast (States of Sinaloa and Sonora)." # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Mexico 1987 max - Oct lastSun 2:00 0 S Rule Mexico 1987 max - Apr Sun>=1 2:00 1:00 D # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Mexico/BajaNorte -8:00 Mexico P%sT Zone Mexico/BajaSur -7:00 - MST Zone Mexico/General -6:00 - CST End of northamerica echo 'pacificnew' 1>&2 cat >'pacificnew' <<'End of pacificnew' # @(#)pacificnew 3.4 # The U.S. House of Representatives passed a bill (H.R. 435) establishing # "Pacific Presidential Election Time" on November 10, 1987; # it has yet (as of January 2, 1988) been approved by the U.S. Senate # or signed into law by the U.S. President. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Twilite 1987 max - Apr Sun>=1 2:00 1:00 D Rule Twilite 1987 max uspres Oct lastSun 2:00 1:00 PE Rule Twilite 1987 max uspres Nov Sun>=7 2:00 0 S Rule Twilite 1987 max nonpres Oct lastSun 2:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone US/Pacific-New -8:00 US P%sT 1987 -8:00 Twilite P%sT End of pacificnew echo 'southamerica' 1>&2 cat >'southamerica' <<'End of southamerica' # @(#)southamerica 1.1 # From Official Airline Guide - Worldwide Edition (1987). Countries not # listed here do not observe DST, according to the OAG. Time zone names # are pure inventions, and none are supplied for countries not observing # DST; updates from natives would be appreciated. The times that DST # starts and ends are based on the assumption that they switch a 2AM just # as everybody else does. # Brazil # The OAG lists October 25, 1987 and February 12, 1988 as the starting and # ending dates, giving them as "estimated date(s) based on previous year". We # infer a rule here from one example, always a dangerous practice.... Yes, # they really do switch on Saturday, according to the OAG. # "Brazil/Acre" is for the Territory of Acre; "Brazil/DeNoronha" is for # Fernando De Noronha. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Brazil 1987 max - Feb Sat<=14 2:00 0 S Rule Brazil 1987 max - Oct Sat<=28 2:00 1:00 D # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Brazil/East -3:00 Brazil E%sT Zone Brazil/West -4:00 Brazil W%sT Zone Brazil/Acre -5:00 Brazil A%sT Zone Brazil/DeNoronha -2:00 Brazil F%sT # Chile # The OAG lists October 11, 1987 and March 12, 1988 as the starting and # ending dates, giving them as "estimated date(s) based on previous year." # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Chile 1987 max - Mar Sun<=14 2:00 0 S Rule Chile 1987 max - Oct Sun<=14 2:00 1:00 D # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Chile/Continental -4:00 Chile C%sT Zone Chile/EasterIsland -6:00 Chile E%sT End of southamerica echo 'asia' 1>&2 cat >'asia' <<'End of asia' # @(#)asia 3.3 # Incorporates data for Singapore from Robert Elz' asia 1.1, as well as # additional information from Tom Yap, Sun Microsystems Intercontinental # Technical Support (including a page from the Official Airline Guide - # Worldwide Edition). The names for time zones are guesses. # People's Republic of China. Yes, they really have only one time zone. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule PRC 1970 max - Apr Sun<=14 2:00 1:00 D Rule PRC 1970 max - Sep Sun<=14 3:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone PRC 8:00 PRC C%sT # Republic of Korea. According to someone at the Korean Times in San Francisco, # Daylight Savings Time was not observed until 1987. He did not know # at what time of day DST starts or ends. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule ROK 1987 max - May Sun<=14 2:00 1:00 D Rule ROK 1987 max - Oct Sun<=14 3:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone ROK 9:00 - KST 1987 9:00 ROK K%sT # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Japan 9:00 - JST Zone Singapore 8:00 - SST Zone Hongkong 8:00 - HKT Zone ROC 8:00 - CST # Israel # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Israel 1987 max - Apr Sun<=21 2:00 1:00 D Rule Israel 1987 max - Aug Sat<=28 2:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone Israel 3:00 Israel I%sT End of asia exit

1 0

New draft C standard
by ado Nov. 21, 1987

Nov. 21, 1987

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

1 0

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

Sept. 1, 1987

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

1 0

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

Sept. 1, 1987

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

2 1

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

Aug. 7, 1987

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

1 0

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

July 24, 1987

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

2 1

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

July 19, 1987

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

2 1

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

May 19, 1987

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

1 0