- tz - lists.iana.org

Indiana time zoning
by Chris Carrier Jan. 30, 1997

Jan. 30, 1997

samrein(a)mainlink.net wrote on the Subj: Indiana Daylight Savings Time >I was just told today that Indiana only has 4 counties that change time >twice a year. Can you tell me which 4 and why? My latest information has 11 counties in Indiana; 6 in the NW part of the state and 5 in the SW; on CST in winter and CDT in summer. The rest of the state keeps EST all year. The reason for the counties in the NW being on CT all year is because they are part of suburban/exurban Chicago and prefer being on Chicago time. The counties in the SW have similar economic ties to Central Time areas in neighboring states and prefer being on Central Time for that reason. The history of Indiana time zoning is more than a little interesting, and I have a fascinating and ahem, rather personal story about it that I will send anyone who is interested. In 1883, when standard time was promulgated by the railroads, Indiana went on CST without much complaint. Indiana observed CDT during the summer-time periods of 1918-19 and all year under the name Central War Time during the American World War II year-round summer-time period of 1942-02-09 to 1945-09-30. It was here that things began to get interesting. At the end of War Time, half of Indiana decided it liked being on CDT or EST all year and the other half didn't. Therefore, from 1946 onwards, you have the phenomenon of counties deciding what time they wished to be on, cities within those counties deciding they didn't like the county decision and adopting their own time, and even some neighborhoods split with one side of town adopting DST and the other not, or a town being on one time and its post office on another, ad nauseum. Shanks has tracked down 255 separate rules for Indiana time zoning on the postwar period, and I'm quite sure even he missed a lot of the little rules. Aggravating this after 1954 is indeterminacy as to whether the summer-time period should end on the last Sunday in September or October (September was near universal 1921-41 and 1946-54, and should still be, IMHO). In the early 1960s there was more confusion as the summer-time period began in most jurisdictions on the last Sunday in April, but in a few was delayed until late May, usually a Sunday preceding or following or the day of US Memorial Day (at that time, May 30 in all years; and in many of these jurisdictions DST ended on either the day of, the day before or the day after US Labor Day; the 1st Monday in September). It remember reading in a magazine printed in the mid-1960s that there was a 35 mile stretch of road in Indiana where the clocks changed 7 times. The Eastern/Central boundary crept west during this period, and was officially moved to cover half of Indiana in 1961, and most of it, excepting the counties that are still on Central, on the last Sunday in April 1970. The Uniform Time Act of 1967 required Indiana to clean its time act up. The Indiana Legislature's response to this was to pass a law requiring one clock in each county courthouse to be set to and be labeled 'official time' and allowed localities to go on as before. The 1972 amendment to the Uniform Time Act allowed states such as Indiana in split time zones to except the zone on the later time from DST. As soon as it was passed the Eastern Zone area of Indiana so exempted itself. As such it remained on EST during the expanded summer time periods of 1974-5. Even today, there is still some un-official time in Indiana, in the counties near the Ohio border, which are officially on EST all year, but some informally use EDT in the summer time period while using EST as the time recorded on official documents such as birth records, timestamping of deeds, etc... Personally they should have stayed in the Central Zone where they astronomically belong. Ohio should have been the scene for this mess (but Ohio has some interesting time tales of its own). Chris Carrier

1 0

Re: Inverse for gmtime() ??
by ncm＠cantrip.org Jan. 22, 1997

Jan. 22, 1997

Chris Newman <Chris.Newman(a)innosoft.com>: > On Mon, 20 Jan 1997, Markus G. Kuhn wrote: > > I just wanted to start writing a ISO 8601 subset -> time_t conversion > > routine, but to my great disappointment I discovered that ISO C does > > not seem to allow portable conversion of a broken-down time into time_t. > > You can do a binary search of the time_t space using the gmtime() > function. This does require the assumption that time_t is an integral > type, but works well. There is no reason to assume that time_t is integral, and good reasons to assume it often is not, and more often in the future than at present. The restricted range of 32-bit time_t values is a problem in common applications, and until 64-bit machines are universal the easiest way to sidestep the problem is "typedef double time_t;". In any case, since time is a continuous quantity a floating-point representation makes perfect sense, and ANSI (aware of this) permits it. Nathan Myers ncm(a)cantrip.org

2 1

Inverse for gmtime() ??
by kuhn＠cs.purdue.edu Jan. 21, 1997

Jan. 21, 1997

I just wanted to start writing a ISO 8601 subset -> time_t conversion routine, but to my great disappointment I discovered that ISO C does not seem to allow portable conversion of a broken-down time into time_t. In other words, while mktime() is the inverse function to localtime(), there exists no mkgmtime() that is the inverse function to gmtime(). I knew that the C standard library time API is a strange design, but I had no idea that it was *that* bad. The only practical way to get from a broken-down UTC time to time_t seems to be to assume that we are on a POSIX system where the time_t representation is exactly specified. Or did I miss something? In case someone of you is in contact with the folks revising ISO C, I have now a whole list of things that should be fixed in time.h: - add inverse function for gmtime() (mkutime() or mkgmtime()) - add to strftime() conversion specifiers for ISO 8601 week-of-year and year-of-week. - remove the second leap second 61 mentioned in the footnote (contradicts to UTC definition) Instead of adding an inverse function for gmtime, one could also extend struct tm by a new field tm_offset, which is in seconds the difference between the time in the struct tm and the corresponding universal time (in my opinion a much cleaner solution than the tm_isdst hack). But I guess, this might break existing code that does not initialize tm_offset ... Having a tm_offset in struct tm would however still be a good idea as this would allow to implement in strftime() conversion specifiers for the time zone offset (much more interesting than the time zone name). Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu

3 2

tzcode1997a.tar.gz and tzdata1997a.tar.gz
by ado Jan. 21, 1997

Jan. 21, 1997

The files ftp://elsie.nci.nih.gov/pub/tzcode1997a.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata1997a.tar.gz are now available. These include Paul Eggert's Antarctica (and other changes). I've finessed the "getopt" issue by checking against both -1 and EOF (regardless of POSIX, SunOS 4.1.1's manual says -1 is returned while SunOS 5.5's manual says EOF is returned). --ado

1 0

interested in your mailing list
by Wayne Olsen Jan. 21, 1997

Jan. 21, 1997

send me information please wayne olsen

1 0

More about Antartica
by Antoine Leca Jan. 21, 1997

Jan. 21, 1997

Hello, I've dig up some informations about timezones in the French Southern Territories. First, a Web page in English is available at <URL:http://www.icair.iac.org.nz/science/reports/fr/IFRTP.html>. IFRTP (Institut Français pour la Recherche et la Technologie Polaire) is the French organism in charge of the scientific stations there. They don't have a web page of their own presently. When they will have one, it will be linked in the proper place in <http://www.mesr.fr/organism.htm>. I called this organism, and Mrs. Nicole Pailleau which is in charge of the communications with the remote stations gave me the local hours there. She confirms me that no stations use daylight saving time, even Terre Adelie that is connected with Tasmania for support. There is really two different zones: * one is the islands in the Southern Indian Ocean, namely Kerguelen, Crozet, Amsterdam and Saint-Paul. There are 3 meteorologic bases, in the Kerguelen, in Crozet and in Amsterdam. They are constantly at UTC+5: Martin-de-Viviès Base, Amsterdam Island, -374105+0773155, since 1950 30 persons in winter, 50 in summer Port-aux-Français, Kerguelen Islands, -492110+0701303, since 1951 80 persons in winter, 120 in summer Alfred-Faure Base, Crozet Islands, -462551+0515152, since 1964 35 persons in winter, 50 in summer St Paul Island, near Amsterdam, is uninhabited since 1927 The islands were inhabited by whale-hunters (with oil factories) in the 1920's. They are supported from the island of Réunion. Since they are really in the Indian Ocean, I give them the zone name of Indian/Kerguelen, the name of the largest island; Indian/Port_aux_Francais ought to be more appropriate, but too long. * the second is a base in the main continent, in a area called Terre Adélie. It is named Dumont-d'Urville, and it lies at UTC+10 all year round. It holds 35 persons in winter and 100 in summer. Previously, there were another base, named Port-Martin; it was destroyed by fire in 1954. I included it in the statitics about the past. Also, I read in <http://www.antdiv.gov.au/aad/exop/sfo/macca/macca_aws.html> that Macquarie Is is in the same timezone as Tasmania. But I don't know if it is inhabited all-year round. I joined two diff files about the changes. *** antarc~1 Sun Nov 24 02:07:38 1996 --- ant.new Mon Jan 20 19:47:06 1997 *************** *** 58,71 **** # France # # French Southern Territories with year-round inhabitants ! # Amsterdam Island ! # Crozet Islands ! # Kerguelen Islands ! # St Paul Island # ! # year-round base ! # Dumont d'Urville, Adelie Land, since IGY # Germany - year-round base # Georg von Neumayer --- 58,95 ---- # France # + # From Antoine Leca <Antoine.Leca(a)Renault.FR> (1996-01-20): + # Timezones from Nicole Pailleau at IFRTP (French institute). + # She confirms that French Southern Territories and Terre Adelie bases + # doesn't observe daylight saving time, even if Terre Adelie supplies came + # from Tasmania. + # # French Southern Territories with year-round inhabitants ! # ! # Martin-de-Vivies Base, Amsterdam Island, -374105+0773155, since 1950 ! # Alfred-Faure Base, Crozet Islands, -462551+0515152, since 1964 ! # Port-aux-Francais, Kerguelen Islands, -492110+0701303, since 1951 # ! # St Paul Island - near Amsterdam, uninhabited since 1927 ! # ! # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Indian/Kerguelen 0 - ___ 1950 # Port-aux-Francais ! 5:00 - TFT # ISO code TF Time ! # ! # year-round base in the main continent ! # Dumont-d'Urville, Terre Adelie (Adelie Land), -6040 +14001, since 1956-11 ! # ! # Previously, another base at Port-Martin, 50km east, was operated since 1947 ! # It was destroyed by fire on 1952-01-14 ! # ! # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Antarctica/DumontDUrville 0 - ___ 1947 ! 10:00 - PMT 1952 Jan 14 # Port-Martin Time ! 0 - ___ 1956 Nov ! 10:00 - DDUT # Dumont-d'Urville Time ! # References ! # <URL:http://www.icair.iac.org.nz/science/reports/fr/IFRTP.html> (1996-01-17). ! # Germany - year-round base # Georg von Neumayer *** zone.tab 1996-11-24 02:07:38 tzdata96n --- zone.tab 1997-01-17 18:38:22 tzdata *************** *** 34,39 **** --- 34,40 ---- AQ -6448-06406 Antarctica/Palmer Palmer Station, Anvers Island AQ -6736+06253 Antarctica/Mawson Mawson Station, Holme Bay AQ -6617+11031 Antarctica/Casey Casey Station, Bailey Peninsula + AQ -6040+14001 Antarctica/DumontDUrville Dumont-d'Urville Base, Terre Adelie AR -3436-05827 America/Buenos_Aires E Argentina (BA, DF, SC, TF) AR -3257-06040 America/Rosario NE Argentina (SF, ER, CN, MN, CC, FM, LP, CH) AR -3124-06411 America/Cordoba W Argentina (CB, SA, TM, LR, SJ, SL, NQ, RN) *************** *** 310,315 **** --- 311,317 ---- SZ -2618+03106 Africa/Mbabane TC +2128-07108 America/Grand_Turk TD +1207+01503 Africa/Ndjamena + TF -492110+0701303 Indian/Kerguelen TG +0608+00113 Africa/Lome TH +1345+10031 Asia/Bangkok TJ +3835+06848 Asia/Dushanbe

2 1

Re: minor fixes for tzcode1996o
by ado＠elsie Jan. 20, 1997

Jan. 20, 1997

> This fixes potential buffer overflows, corrects getopt(3) usage > (getopt(3) returns -1, not EOF these days), and adds another > PCTS tweak to pass an arguably bogus test. The diff is reversed, > sorry about that. > ... > --- time/localtime.c Mon Jan 13 20:17:09 1997 > ... > - if ((strlen(p) + strlen(name) + 2) >= sizeof fullname) > + if ((strlen(p) + strlen(name) + 1) >= sizeof fullname) > return -1; > ... There's a problem if the number of characters in a to-be-generated full file name (exclusive of the trailing '\0') equals or exceeds the size of the filename buffer. The number of characters (exclusive of the trailing '\0') is strlen(p) + strlen(name) + 1 (where the "1" is for the slash that separates the directory from the name) and the size of the filename buffer is sizeof fullname It looks to me as if the above test is correct; does anyone see something I've missed? > --- time/zdump.c Mon Jan 13 20:17:17 1997 > ... > (void) strncpy(buf, abbr(&tm), (sizeof buf) - 1); > - buf[(sizeof buf) - 1] = '\0'; > ... > (void) strncpy(buf, abbr(&newtm), > (sizeof buf) - 1); > - buf[(sizeof buf) - 1] = '\0'; > ... > (void) strncpy(loab, abbr(&lotm), (sizeof loab) - 1); > - loab[(sizeof loab) - 1] = '\0'; The strncpy's above all have static arrays as their destinations; since the static array's are initialized to '\0's, and since the strncpy's can't change the last positions in the arrays (given the "- 1"s in the strncpy arguments), the sets of the last elements to '\0' seem unneeded. Does anyone see something I've missed? > --- time/zic.c Wed Jan 15 16:41:36 1997 > ... > - while ((c = getopt(argc, argv, "d:l:p:L:vsy:")) != -1) > + while ((c = getopt(argc, argv, "d:l:p:L:vsy:")) != EOF) If anyone knows a good way of conditionalizing this (to cope with, for example, SunOS 4.1.1), I'd appreciate hearing from you. --ado

2 1

Minute offsets
by Chris Carrier Jan. 17, 1997

Jan. 17, 1997

Markus G. Kuhn wrote: > I do not have very strong feelings about the optionality of the minute > offset, but my arguments for it are: > - only *very* few countries use it today and time zones are so often > redefined that there is some good hope that the 30-min offset zones > will disappear in 2020 or so. Then, we would not carry around > any more the obsolete minute fields in our headers. > - I personally think that the hour only offset is much more readable > and that the additional implementation effort (one single "if" in > my sample code) is so trivial that it is really not worth any > discussion. I would make minute offsets mandatory, because we are discussing not only contemporary but historical time zone data, when minute offsets were more common. Also IMHO minute offsets are not necessarily a Bad Thing; a small country without any of its territory going through an hourly meridian but with territory going through a minute offset might be better served by the minute offset zone; Portugal and Ireland, for example, fit GMT-0:30 closer than GMT or GMT-1. What I would favor is putting a colon in between hours and minutes, for readability; i.e. the time in Darwin, Australia is easier to read as GMT or UT+09:30 than as +0930. My $0.02 worth...

3 2

Re: C Code for draft-newman-datetime-00.txt
by Antoine Leca Jan. 17, 1997

Jan. 17, 1997

Hi Ken, Hi Tom, Tom Peterson wrote: > > Since ISO C doesn't appear to present restrictions here and TOG says they > > don't support negative time_t's, perhaps this is an area where an industry > > precedent should be set. I've yet to see an errno defined for mktime() on > > other systems, but I don't see anything precluding it. Is this something we > > should consider adding to the tz code base? and Ken Pizzini answered: > > The question I have to ask here is: are we working on an ANSI/ISO C > standard compatible interface, or a POSIX/TOG based standard? If > the latter we can work with the understanding that time_t values > represent seconds since some epoch It's my understanding that the current TZ code request it. > and consider following TOG's > lead in saying that negative time_t values are not allowed. OTOH, I don't fell this is requested by the current code base. > But if we are working on something that trancends POSIX compliance > and should work on any standard C system then I don't feel that > we can reasonably rule out negative time_t values -- the C > standard allows far too many possible underlying semanatics > for time_t values. However, we can't aim at full C portability, since the code base made in *many* places the assumption that time_t is an integral type, counting seconds. And the C standard clearly states other implementations are possible. So, as you and Tom point out, we are "between two chairs". > > Is there an existing errno value/macro that > > would fit the description of "time is not representable"? > > The best existing one I see is ERANGE, but the explanitory text > on this system says "Result too large", so it isn't perfect. > (I feel that the description has a bug myself -- a range error > really does encompass more than just "too large" a result.) As the current standard says, this seems correct. ERANGE is used for signaling overflowing of mathematical operations. And the standard explicitly says that it *could* be used for signaling underflows, but doesn't enforce this behavior. If your system don't do it, "Result too large" seems a good description to me. I don't like the idea of re-using ERANGE, because mktime() can fail for others reasons than excessing the available values for time_t (one obvious example is a time in the autumn overloapping period with tm->tm_isdst==-1). I think a new constant is in order (I don't like the idea of a new signaling mechanism); what about EILTIME? Furthermore, since mktime can fail for different reasons (before Epoch, result too large, wrong DST setting, autumn indetermination, spring gap; others?), perhaps can we set up different constants? I also want to bring this discussion to <news:comp.std.c> as well, in part for bringing this to the attention of the members of the comittee in charge of C standardization, in part for asking the C gurus about the choice of an ESOMETHING constant(s). Amicalement, Antoine

1 0

Re: C Code for draft-newman-datetime-00.txt
by Antoine Leca Jan. 17, 1997

Jan. 17, 1997

Tom Peterson (USG) wrote: <from Ken Pizzini> > > A problematical situation on any implementation is distinguishing > > between an error return from mktime() and mktime() returning a > > legitimate -1 value. [...] > > An error code (or errno) would help here I think. If errno were set to a > particular value when mktime() really couldn't represent the value, we'd have > a way to distinguish between a valid -1 and and error -1 return value. I agree with you. > Problem is, we'd have trouble getting the standards like X/Open to accept > this, since they claim they don't support negative time_t's (ie: times before > the Epoch). Strictly speaking, mktime() is not a X/Open standard, but part of the standard C library. So IMHO, the solution lie more in the realm of ISO/JTC2/SC22/WG14 (the comittee in charge of C standardization) than in X/Open. And BTW, ISO C doesn't put any restriction on the range of the value of the time_t (which is only arithmetical, not necessary [un]signed long int); and Epoch does take any sense as long as ISO C is concerned. Best regards, Antoine

1 0