- tz - lists.iana.org

UK Summer Time Order 1994
by Peter Ilieve Dec. 1, 1994

Dec. 1, 1994

The final piece of the legislative jigsaw for summer time in the UK for 1995--97 is now in place. The Summer Time Order 1994 (SI 1994/2798) came into force on 16 November. It restates the dates from the EC seventh Summer Time Directive which are already reflected in the tzdata files. Peter Ilieve peter(a)memex.co.uk

1 0

Summertime in the EU in the future [forwarded with permission]
by ado Nov. 30, 1994

Nov. 30, 1994

> From cutter!nrs Tue Nov 29 09:23:31 1994 > Return-Path: <cutter!nrs> > Received: from ns.dknet.dk by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA07009; Tue, 29 Nov 94 09:23:28 EST > Received: from pingnet by ns.dknet.dk with UUCP id AA11329 > (5.65c8/IDA-1.4.4j for ado(a)elsie.nci.nih.gov) Tue, 29 Nov 1994 15:23:24 +0100 > Received: from spiggy by ic1.ic.dk with UUCP id AA08239 > (5.65c8/IDA-1.4.4j for elsie.nci.nih.gov!ado); Tue, 29 Nov 1994 15:15:27 +0100 > Received: by cutter.gtv.dk (Smail3.1.28.1 #52) > id m0rCTDP-000iavC; Tue, 29 Nov 94 15:07 CET > Message-Id: <m0rCTDP-000iavC(a)cutter.gtv.dk> > From: nrs(a)spiggy.ping.dk (Niels Svennekjaer) > Subject: Summertime in the EU in the future > To: ado(a)elsie.nci.nih.gov (Arthur David Olson) > Date: Tue, 29 Nov 1994 15:07:31 +0100 (CET) > X-Mailer: ELM [version 2.4 PL23] > Mime-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > Content-Length: 710 > X-Charset: ASCII > X-Char-Esc: 29 > Status: RO > > Hello Arthur > > Following comes from the danish newspaper "Berlingske tidene" > 29.Nov. 1994: > > >From 1996 the summer time will be the same in all EU (The European Union) 15 > memberstates : > > Austria, Belgium, Denmark, Finland, France, Germany, Greece, Great Brittan, > Holland, Irland, Italy, Luxemburg, Portugal, Spain, & Sweden. > > > And it will last from the last sunday in March to the last sunday in > October. At the moment GB & Irland have another endingdate for the ST > then the rest of the EU. > > So in 1995 the ST will start 26.March, and end 24.Sep in all EU countries > (EXCEPT GB & IRLAND) > > Then in 1996 all EU countries, the ST will bee from 31.March to 27.Oct. > > Greethings from Denmark, (& Niels Svennekjaer)

1 0

Internet address change for elsie.nci.nih.gov
by ado Nov. 25, 1994

Nov. 25, 1994

The Internet address for elsie.nci.nih.gov has changed from 128.231.16.1 to 165.112.73.1; assuming the name servers do their things, this change should be invisible to folks who use the name rather than the address. --ado

1 0

Re: Canadian bilingual time zone names
by ado Nov. 23, 1994

Nov. 23, 1994

> I think probably the best thing is to leave this to the multilingual > handling stuff each system has. > > In message catalog systems, I think it is easy to use the current zone names > as the key to language-specialized message catalogs of time zone names. One thing the multilingual handling stuff might not handle well would be the names of time zone files, which are what's used to establish the time zone to be used. A possibility here would be to take the tack used with the "backward" file in the distribution: set up a file (named, for example, "espanol") with lines such as Link America/Mexico_City America/Ciudad_Mejico and provide instructions on how system administrators can zic espanol to generate language-specific stuff. --ado

1 0

Canadian bilingual time zone names
by eggert＠twinsun.com Nov. 16, 1994

Nov. 16, 1994

I enclose below (with permission) copies of Usenet articles written by Alain LaBont<e'>, which cover the Canadian standard for multilingual time zone names. (I've told him about the tz tables.) At first I thought I'd propose to duplicate all the Canadian Zone and Rule lines, one copy for English and one copy for French. But now I'm not so sure, since this practice would greatly balloon the tables if we did it for all multilingual locations. The topic of multilingual time zone names seems to have slipped through the standardization cracks, since the LC_TIME environment variable doesn't address this issue. One way out of the problem would be to extend the syntax of the TZ environment variable to allow optional specification of the names of the standard and daylight zone names before the name of the file. E.g. `TZ=America/Halifax,HNA,HAA' for people in <I^>les-de-la-Madeleine who want French time zone names. This is a bit of a hack, since it doesn't address the issue of double-daylight zone names, or changes in zone names over time, but it may be the most practical solution. Another way would be to extend LC_TIME somehow to cover time zone names. This sounds less plausible to me, since there are dozens of time zones and most locales don't care about names of time zones on the other side of the planet. From: ALB(a)immedia.ca Newsgroups: comp.software.international Date: 14 Nov 1994 14:39:23 -0500 Message-ID: <3a8edb$781(a)senator-bedfellow.MIT.EDU> Now as promised, I post here the time zone abbreviations standardized in Canada for both English and French in CAN/CSA-Z234.4-89 standard (I have added notes and corrected minor typos still in the standard/ the abbreviations and numeric and alphabetic time zones are correct in the standard, what I corrected would not change any technical content). Table A2 - Canadian Time Zones Abbreviations (Abr<e'>viations des fuseaux horaires pour le Canada) Standard Time Daylight Saving Time ITU Designator Hours West French English French English of UTC HN- -ST HA- -DT 2-1/2 - - HAT NDT - 3 - - HAA ADT P 3-1/2 HNT NST - - - 4 HNA AST HAE EDT Q 5 HNE EST HAC CDT R 6 HNC CST HAR MDT S 7 HNR MST HAP PDT T 8 HNP PST HAY YDT U 9 HNY YST - - V HN stands for "Heure normale"/HA stands for "Heure avanc<e'>e" ST stands for "Standard Time"/DT stands for "Dailight saving Time" Prefix/Suffix meaning (note from ALB: I added the appropriate prepositions and articles "du, de l', des, de" for non-French speakers, so that the information of the standard be completed for them - this data is not in any version of the std.): A: Atlantic/de l'Atlantique C: Central/du Centre E: Eastern/de l'Est M: Mountain (note from ALB: see R for French) N: Newfoundland (note from ALB: see T for French) P: Pacific/du Pacifique R: des Rocheuses (note from ALB: see M for English) T: de Terre-Neuve (note from ALB: see N for English) Y: Yukon/du Yukon Note: The standard says (I cite the English version textually): "Although there is no ISO standard on time zone designators, the letters given in table A1 have been adopted by the International Telecommunication Union (ITU/[UIT in French]), a UN ["Nations Unies" in the French version, normally abbreviated ONU] special agency having the status of treaty organization regarding radio operations and regulations. Within North America the abbreviations given in table A2 are also used." The standard also deals with all-numeric dates and times (Repr<e'>sentation num<e'>rique de la date et de l'heure). I invite those who want non-time-zone-related information on this subject to buy the standard from CSA (Canadian Standards Association/Association canadienne de normalisation) sales offices throughout the world. I only cited here the full table A2. Table A1 starts with Z for UTC, goes from A to M East of UTC (with M as a half-zone) and N to Y West of UTC (with Y as a half-zone); the Newfoundland half-zone does not seem covered by ITU/UIT, despite it is on the soil where the first transatlantic (first long range) radio transmissions were done by Marconi. Quarter zones are not covered either by ITU, even if this does not affect Canada, but certain countries. I also think that what would be good to document would be the dates on which standard and daylight-saving time changes are done throughout the world. I have not found that data in any place. I think it can *not* be done only on ITU designators, as it has to take into account at least Northern/Sourthern hemisphere and even national/multinational conventions and laws (for example, this fall, Britain, Europe and North America have all switched to Standard Time at different dates [3 dates...], sometimes at weeks of interval !!!) For other countries it is quite problematic... from time to time, laws change too. Perhaps there is a need for a worldwide registration authority for that matter. Alain LaBont<e'> Gouvernement du Qu<e'>bec Secr<e'>tariat du Conseil du tr<e'>sor Service de la prospective et de la francisation ----------- end of message 1 ----------- start of message 2 Destinat. (CA-JTC1-SC2(a)MICROSTAR.COM, CPWG-MAIL(a)REVCAN.CA, SC22WG20(a)DKUUG.DK) Objet : Mnemonics for the ITU assigned time zone codes... Envoyeur: RNET (ALB(a)immedia.ca) Date : 11/15/94 Time : 21:17 ---------- It is interesting to note that there is a mnemonic way to remember the time zone codes attributed by ITU for North America. Q applies to at least one of the two time zones of Quebec at any time of the year (Eastern Daylight Time in the summer, Atlantic Standard Time in the winter). Remember "Quebec in the summer", the most beautiful time of the year... For R, remember "Rivi<e`>re-du-loup West of the Atlantic": (see below) 4 HNA AST HAE EDT Q 5 HNE EST HAC CDT R FYI: Atlantic time zone used to begin West in Rivi<e`>re-du-loup when I was a teenager (to respect exact time zone calculations that divides the world into 24 equal parts). For convenience, all continental Quebec is on Eastern Time all the time now while the Atlantic Time Zone, because it is quite far East, applies to <I^>les-de-la-Madeleine, which is predominently-French-speaking Quebec even if you have to cross 2 other provinces (NB and PEI) to access it (it was populated by deported Acadians, and more recently by St.Pierrans and Miqueloners [from "neighbouring" St-Pierre-et-Miquelon, France]). On the continent, in Canada, you cross the Eastern zone to the Atlantic zone when you cross the bridge between Quebec and New Brunswick (between Matap<e'>dia and Campbelton). Interesting to note also that in the aviation jargon worldwide, the letter Q is pronounced Quebec (ALPHA... BRAVO... ... QUEBEC ... TANGO ... ZULU). When taking my first flight lessons at the Quebec airport in the eighties, I was puzzled about why they were identifying the control tower by "QUEBEC BRAVO" ("Why were they adding BRAVO?", I did not know... at the second lesson I heard it was the standard way of identifying the airport, whose code is YQB! [Y is for Canada and is obvious, it seems]) Z (i.e. ZULU) is assigned to UTC time zone (i.e. the time zone whose centre is at the Greenwich Observatory Meridian). Alain LaBont<e'> Gouvernement du Qu<e'>bec Secr<e'>tariat du Conseil du tr<e'>sor Service de la prospective et de la francisation

2 1

DST hits police blotter
by ado Oct. 31, 1994

Oct. 31, 1994

The "Names & Faces" column in the Monday, October 31, 1994 Washington (DC) Post, page D3 (compiled from staff and wire reports by Marla Harper) contains a "Daylight-Saving Bust" item. Erik (son of Kirk) Douglas was arrested after arguing with a Denny's manager who wouldn't serve him a drink. "...Douglas had insisted he be served, saying the one-hour shift to Pacific Standard Time made it 1 a.m.-- and within the 2 a.m. cutoff for alcohol sales..." --ado

1 0

DST article in Washington Post
by ado Oct. 27, 1994

Oct. 27, 1994

The article "What Time Is It Anyway? It Depends on Your Location & the Season" with a sidebar "Brief History of Daylight Savings" appears in the Thursday, October 27, 1994 Washington (DC) Post, page D5. The author is Cathy Grubman, who relies extensively on Joanne Petrie ("Mother Time") of the US Department of Transportation. --ado

1 0

Confirmation of data for Estonia
by Peter Ilieve Oct. 15, 1994

Oct. 15, 1994

I apologise in advance to whoever produced the data for Estonia in the 93e data as they may have known it was authoritative, but there is no source given. A relative in Tallinn confirms the accuracy of the data for 1989 onwards and gives the legal authority for it, a regulation of the Government of Estonia, No. 111 of 1989. It is interesting to me that changing their timezone arrangements was one of the first things they did in the process of getting out from under 50 years of Soviet occupation. My source doesn't know if any changes will be made in 1996 and beyond to track the change in EU dates specified in the European 7th directive. Even though the dates are currently the same the Estonians change an hour before the EU, at midnight GMT. Peter Ilieve peter(a)memex.co.uk

1 0

New Daylight Savings dates for South Australia
by John Warburton Oct. 7, 1994

Oct. 7, 1994

Hello, I belive that the timezone files are being centrally managed by you. You will be interested to know that the new Daylight Savings dates for South Australia (zone Australia/Adelaide*) was gazetted in the Government Hansard on Sep 26 1994. start: Sunday 30 October end: Sunday 26 March i.e. start on last Sunday in October and end in last sunday in March. (*) Just a note of concern. Vendor distributed timezone file that I have seen (SunOS, UnixWare) describe timezones by Australian state eg Australia/South, Australias/Tasmania etc, rather than this new method of naming zones by the capital city. I'm just wondering where it came from & is it really correct, as timezone affect the whole stae and not just the capital city. John (who fears daylight savings each year...) -- John Warburton jwarb(a)SACBH.com.au ASPECT Computing email address valid until 31/12/94 You miss the vendor... The vendor hits! The vendor hits! The vendor hits! --More-- You die...

1 0

[bugs@freebsd.org: Re: Timezone bug in 1.1R]
by Garrett Wollman Sept. 25, 1994

Sept. 25, 1994

I will fix this in FreeBSD; here is the problem for the benefit of other TZ users... ------- start of forwarded message (RFC 934) ------- Message-Id: <199409250603.GAA18199(a)apu.fi> Precedence: bulk From: Hannu Strang <chs(a)apu.fi> Sender: bugs-owner(a)freebsd.org To: bugs(a)freebsd.org Subject: Re: Timezone bug in 1.1R Date: Sun, 25 Sep 1994 06:03:37 GMT > Well, here in Helsinki we're just changing from summer time to > regular one, and it's supposed to change at 4am... > This 1.1R box just changed the time, and it's now only 3am. > So the change is off by one hour... Not that it matters too > much, just felt like reporting it. > > Is the timezone code changed in 1.1.5.1 or 2.0? > >lrwxrwxr-x 1 root 35 Jun 10 22:09 /etc/localtime -> >/usr/share/zoneinfo/Europe/Helsinki There seems to be an error in /usr/src/share/zoneinfo/europe also in 2.0. Zone for Finland (Europe/Helsinki) ends up with line 2:00 M-Eur EET%s which should be 2:00 E-Eur EET%s instead. Zone EET (which I have been using) is correct. Estonia, Latvia, Lithuania, Bulgaria, Greece, Moldova, Romania, Turkey, Ukraine (Europe/Kiev) look suspicious the same way but I don't know about them. ------- end -------

1 0

South Australia fools around with it's timezone again
by Mark Prior Sept. 21, 1994

Sept. 21, 1994

Just when I thought the politicians had got some sort of system into our magic roundabout of a timezone they play about with it again! It appears that even though there is no Adelaide Festival next year we are ending daylight saving on March 26 (ie we are using the even year rule in an odd year). Apparently we are doing this to stay in line with Victoria and Tasmania so maybe this is for Moomba or something. NSW and ACT are finishing daylight saving as usual on March 5. At least they haven't played with the start of daylight saving which is still the last Sunday in October. So next year's rule is Rule AS 1995 only - Mar 26 2:00 0 - Mark.

4 5

time zone map
by ado Sept. 4, 1994

Sept. 4, 1994

A time zone map of unknown pedigree is available from wuarchive.wustl.edu; the file is multimedia/images/jpeg/unindexed/940901/timezon2.jpg. --ado

1 0

mktime() failures under PCTS testing
by eggert＠twinsun.com Aug. 31, 1994

Aug. 31, 1994

If you'll recall, the tz package `mktime' normally returns -1 when given a time in a `spring-forward' gap, but the NIST-PCTS:151-2 test suite, Version 1.4, (1993-12-03), claims that this is a bug. In March I submitted a formal Defect Report about this to the committee responsible for the C Standard, and have just received a copy of the draft response (SC22/WG14 DR#136). This response has been approved by WG14 but is subject to a final review, so it is not official yet. The response reads as follows: The Standard does not specify the behavior precisely enough to preclude `mktime' from returning a value of `(time_t)-1' and leaving the `tm_isdst' member set to -1 in such situations. In other words, assuming this response becomes official as expected, PCTS must not insist that mktime yield a value other than -1 in such situations. Perhaps someone who's familiar with PCTS (which I am not) can forward this info to PCTS's maintainers. Here's the example program that I submitted as part of Defect Report #136. According to the draft response, a conforming implementation in a U.S. locale can print `mktime failed' when presented with the following program, since the requested time is in a `spring-forward' gap. #include <stdio.h> #include <time.h> int main() { struct tm t; time_t r; /* 1994-04-03 02:30:00 */ t.tm_year = 1994 - 1900; t.tm_mon = 3; t.tm_mday = 3; t.tm_hour = 2; t.tm_min = 30; t.tm_sec = 0; t.tm_isdst = -1; /* i.e. unknown */ r = mktime(&t); if (r == -1) printf("mktime failed\n"); else printf("%s", ctime(&r)); return 0; }

1 0

FYI - More on Six Digit Dates
by Monty Solomon Aug. 26, 1994

Aug. 26, 1994

Begin forwarded message: Date: Fri, 26 Aug 1994 09:56:09 -0500 (EST) Newsgroups: tdr.problems From: Problem Reporting Service <PROBLEMS(a)tdr.com> Organization: Tansin A. Darcos & Company, Silver Spring MD USA Errors-To: PROBLEM-ERRORS(a)tdr.com Subject: 0027 - Responses to Issue #26 (Digest, Long) To: Recipients of list Problems <PROBLEMS(a)tdr.com> Problems Digest Fri, 26 Aug 1994 Volume 94 : Issue 27 Today's Topics: Reasons for Creating #26 Re: Six Digit Dates (20 Msgs) Administrivia: Feel free to circulate this or other PROBLEMS messages. To Reply to this or any earlier PROBLEMS message, write to <PROBLEMS(a)TDR.COM>; for private replies or subscriptions use <problems-request(a)tdr.com>; or use newsgroup <tdr.problems>. Please feel free to redistribute this article widely. This message is file ftp.digex.net:/pub/access/tdarcos/0027 ---------------------------------------------------------------------- Date: Date: Sun, 21 Aug 1994 15:14:01 -0500 (EST) From: Paul Robinson <PAUL(a)TDR.COM> Subject: Reasons for Creating Problems #26 Many of you were already aware of the issue of 6-digit dates. The point being that whining about "oh dear oh my oh no we're all going to die when the plants blow up" doesn't solve anything. The main issue - and some other people also gave out some excellent suggestions - was to think up a method to {solve} the problem. We already know the problem exists (or at least I hope most of us do), but finding a solution to the problem wasn't well publicized. The best solution in response to my posting comes from On the secondary note, yes, I am aware that "technically" the century ends on December 31, 2000. But the problem we have is the "de facto" end of the century which is the day after 12/31/99 when six digit dates roll over to 01/01/00. About one advantage we have is that it's a Saturday. (I looked it up. The real issue is come Monday, 3 Jan 2000 when people are not going to be pleased by what has happened.) I say "de facto" meaning the date when virtually everyone will celebrate the end of the 20th Century (December 31, 1999) as opposed to the logically correct "de jure" end of the Century of December 31, 2000). There is a good discussion on this issue in James Michener's "Texas", where some people in the 1890s are discussing when the 19th Century ends. The Intelligent people point out that time in AD started with year 1, therefore each century is 100 years and thus the 19th century ends on December 31, 1900, which is 1900 years later. The book also has an hilarious religious discussion where a preacher "solves" the issue by expostulating that God made the first century only 99 years long! So, the half-dozen or so people who logically arrived at 1901 as the beginning of the new century, celebrated then. ------------------------------ Date: Fri, 12 Aug 1994 22:42:30 -0600 From: Daniel Packman <pack(a)acd.ucar.edu> To: PROBLEMS(a)tdr.com Subject: Re: Six Digit Dates > By coding the date into a character field, effectively in base 32, it > would be possible to encode a larger date and still only use 6 characters. As a programmer involved exclusively in the scientific area, it is instructive to see how things are done in "the real world". One rather standard way to encode date in the scientific world is the Julian Date which as a binary 32 bit number is both more compact and covers a greater range (more than 4000 years into the past and future). [MODERATOR'S NOTE: Good idea, if the application can support using binary. I suspect most of the old applications using 6-digit dates are COBOL programs using either "USAGE IS DISPLAY" (6 characters) or "USAGE IS COMP-3" (Packed Decimal). Some of these systems may be running applications that display dates or that can't do binary conversions, but can handle string conversions. This is why I felt a "string" format was better than a binary format. But that's a matter of taste. What counts is what will work. Switching to a DISPLAY format or a non-binary format might allow a minimal change to these old programs, some of which may be older than some of us reading these messages! But if there is an effective means to allow programs to maniuplate julian dates in binary, that's not a bad idea.] ------------------------------ Date: Sat, 13 Aug 1994 07:27:52 -0400 (EDT) From: Larry Nathanson <lan(a)panix.com> To: Problem Reporting Service <PROBLEMS(a)tdr.com> Subject: Re: Six Digit Dates Just one point-- that it might be wise for companies to start testing their machines by resetting their system clocks ahead and seeing what breaks... The risks of causing errors by testing may well be outweighted by the risks of letting things go till 2000 is months away... [MODERATOR'S NOTE: Another good idea. Only problem is you may not be able to do this in all circumstances. Does a bank change the time on its ATM network to see what happens? :) Yes, yes, if someone's running a mission-critical system I would hope they are running a duplicate system or independent system to allow testing, e.g. there is a separate set of ATM machines that are connected to the duplicate system and they dispense memos instead of cash, and can be used for testing the network and its updates. At least I *hope* they are doing this...] ------------------------------ Date: Mon, 15 Aug 1994 10:03:23 -0400 (EDT) From: "John G. Otto" <otto(a)garnet.acns.fsu.edu> To: problems(a)tdr.com Subject: Re: Six Digit Dates > ...The problem is probably not as bad as it was, because with the > introduction of IBM PCs which support dates past the year 2100, > the issue isn't a problem except to the extent of programs that > still use six-digit dates... > What do we need to do? > (1). If your site has inhouse applications, and lots of source files, > you need to push for the acquisition of automated checking tools. > (2). You need to push for the manpower and resources necessary to do the > work now rather than later, because "later" won't be budgeted for. > (3). You need to push for the updating of databases to allow full > 8-digit dates. > (4). Push for all reports to eliminate use of 6-digit dates, even in > display fields. > (5). Find out what your vendor is doing if you use canned applications. Well, yes, the solution is to stop the problem. The ISO standard for dealing with dates (8601:1988 superseding 2014, 2015, 2711, 3307 & 4031) has been around for a while; Control Data was beginning to make use of it some 15 years ago. Interestingly enough, Gary Houston, the author of the summary available on-line, does not follow the standard himself within that summary, using little-endian form (as is customary in Europe, and as opposed to month first inside-out form customary in the USA). An example of ISO 8601:1988 compliant date/time is: 2001-01-15T14:23:38 or 20010115T142338 One nice feature of the form is that it sorts as one field without converson. [idea regarding using alpha to cram more into same size date field deleted] > If we work on the problem now while there is time, we can do this with > less error and better control, than trying to rush fixes in November of > 1999 when errors could spell disaster. Think of it as employment security. :B-)} jgo [MODERATOR'S NOTE: I believe the 6-digit date form is a FIPS Standard and is required in certain government computing applications. Anyone know if this was true and if this was ever repealed?] ------------------------------ Date: Mon, 15 Aug 1994 10:07:08 +0700 From: Tyrannosaurus Wes <wes(a)windjammer.raxco.com> To: PROBLEMS(a)tdr.com Subject: Re: Six Digit Dates >>>>> "0026" == Problem Reporting Service <PROBLEMS(a)tdr.com> writes: 0026> The problem is the issue of six-digit dates and the turn of 0026> the century, now less than six years away. 0026> And I thought of a method. 0026> In fact, if one wants to encode the month and day - Month 0026> encoded to add A,B and C and day encoded as 1-9 and A-V, it 0026> is possible to use 4 digits for the year and still fit 0026> everything into 6 bytes. Or encode both and fit everything 0026> into 4 bytes. 0026> This would also then work for places using packed decimal 0026> for the six-digit year and thus only allowing 4 bytes. Most modern languages, operating systems, and database management systems have some sort of intrinsic date format. Whenever software systems are modified to support extended date handling, a better approach, I feel, would be to convert the 6-character date fields already in use to the "native" date format. Modern languages and DBMS provide support for manipulating dates in these formats, alleviating problems with oddities like leap-seconds, leap-centuries (of which 2000 is one), and the like. Data-file conversion is an issue with this method, but is an issue with any method; the dates *must* be converted. Since this method may require expanding the date field, the availability of direct-access storage may become an issue. -- Wes Peters -- software engineer, network coordinator, system wrangler, chief cook and bottle washer, Raxco Inc., Orem UT Wes(a)Raxco.COM [MODERATOR'S NOTE: That was exactly what I was worried about. I had to think of some method that would use the same amount of space or less, yet still cover a full date field. Also, there is still some software that only generates 6-digit dates. I think DBASE III's DATE() function returns a date in the form MM/DD/YY. Not good.] ------------------------------ Date: Tue, 16 Aug 1994 15:11:46 -0500 From: Tim Horrigan <u2re9toh(a)hanover-crrel.army.mil> To: PROBLEMS(a)tdr.com Subject: Re: Six Digit Dates It's a sad commentary on human nature that this problem wasn't anticipated 35 years ago when this software was first being written. This problem is coming up and biting organizations much earlier than one might think. For example, Dartmouth College (like many colleges, presumably) belatedly discovered last winter that it was possible to have members of the Class of '00 being registered as soon as that coming summer (i.e, what is now right now.) (This happens, for example, if some kid opts for a 5-year program such as a 3-2 Engineering program and then decides to take a year off before starting her course of study.) They _think_ they found all the date fields in their software, but of course they can't be sure. Disclaimer: The views expressed in this message are certainly not those of the Army Corps of Engineers, and they might not even be mine if I were to take the time to think things through a little more thoroughly :-) ------------------------------ Date: Tue, 16 Aug 1994 14:11:36 -0500 From: "Patricia J. Seymour" <pseymour(a)iseg01.imd.cig.mot.com> To: problems(a)tdr.com Subject: Re: Six Digit Dates Hello- I've just read the article "Danger of Six-Digit Dates" in the latest Risks Digest. I understand and agree about the magnitude of the problem, but I don't understand why you are considering Friday, December 31, 1999 to be the "last date of this century." Centuries have one hundred years in them, not 99. The true eve of the next century is December 31, 2000. (That's why the film was entitled "2,001") It's the same as trying to buy something that costs $2,000 with only $1,999 in your pocket. (We are assuming tax as already being figured in the price. :) ) -Patricia (Illinois) [Moderator's Note: Yeah, yeah, I know and I got burned on this one; I am aware of the issue, and intend to use it as an excuse to celebrate twice! Seriously though, does anyone think we're going to convince the vast majority of people, or TV programs doing reviews of the 20th Century that it ends on December 31, 2000? Assuming Dick Clark is still around (doesn't that man ever get any older??) want to bet his show on December 31, 1999 is going to claim we are beginning the 21st Century! ] ------------------------------ Date: 16 Aug 94 16:05:01 EDT From: A S Oliphant <100126.2551(a)compuserve.com> To: Problem Reporting Service <PROBLEMS(a)tdr.com> Subject: Re: Six Digit Dates Interested to read your mail. I have been suggesting such scenarios to several employers over the last 15 years. In fact my current one is starting to grapple with the issue at the moment. However, by a quirk of fortune, our problem is possibly not as big as you suggest. Without naming names, I work in the life assurance business. We computerised early on and dates presented us with similar, if opposite, problem then. That was the need to record dates of birth for existing policy holders born in the 19th century. We therefore devised a method using 4 bytes as follows: Byte 1 - day of month Byte 2 - month Byte 3 and Byte 4 - year (+sign) e.g. 194C is 1994, the C is the sign to make the whole field look like packed decimal (ebcdic). While we have to write special routines to decode and manipulate these dates, it means that our end of century conversion will not be as onerous as for some. [Moderator's Note: I'm glad to hear that. This one isn't too bad a suggestion. There are several good ideas being given out here, and I hope some of them will help people fix their systems before they collapse.] ------------------------------ Date: Tue, 16 Aug 94 14:27:36 PDT From: Andrew Klossner <andrew(a)frip.wv.tek.com> To: PROBLEMS(a)tdr.com Newsgroups: comp.risks Subject: Re: Six Digit Dates Just in case nobody else pointed this out ... "The last date of this century is Friday, December 31, 1999." The last date of this century is 1 January 2000. Centuries run from x01 through x00, because there was no year zero. [Moderator's Note: Yeah, yeah and it's illegal to drive 70 MPH on a public highway in the U.S., but people still do it. I made the mistake of admitting that I, on the occasional time I rent a car because I have to go somewhere, *do* usually drive 55 in the fast lane of the freeway, and people considered *me* a criminal. It's not popular to be 'de jure' correct when that is entirely different from what the general public sees as the 'de facto' correct answer.] ------------------------------ Date: Wed, 17 Aug 94 11:02:52 +0200 From: Udo Voges <voges(a)iai.kfk.de> To: PROBLEMS(a)tdr.com Subject: Re: Six Digit Dates If a solution to this problem is found, it should include the correct international representation of the date, eg. year/month/day, which solves also the misunderstandings with month/day/year and day/month/year. [Moderator's Note: Good point. More than half of the addresses on this list are identifiable as being outside of the U.S., Canada or Mexico, not counting the .COM or .EDU sites that might also be. There are probably three major formats for dates, e.g. M/D/Y as the U.S. does it, D/M/Y is common in Europe or Japan, and Y/M/D as is also used in Japan, I think. Possibly I should write an Internet Draft for publication as an RFC to publicly define a standardized date format for computer data files and to help fix the six-digit issue. Any suggestions?] ------------------------------ Date: Wed, 17 Aug 94 11:38 BST From: mathew <mathew(a)mantis.co.uk> To: problems(a)tdr.com Newsgroups: comp.risks Subject: Re: Six Digit Dates Mike Sullivan <74160.1134(a)compuserve.com> quotes: >>From: Problem Reporting Service <PROBLEMS(a)TDR.COM> >>Subject: 0026 - Exactly. What do we do? (Six Digit Dates) >>Date: Fri, 11 Aug 1994 23:00:58 -0500 (EST) [...] >The last date of this century is Friday, December 31, 1999. 12-31-99. >Want to tell me what the next date after that is? Saturday, January 1, 2000. >01-01-00. Incorrect. The last date of this century is Sunday, December 31st, 2000. The first date of the 21st century is Monday, January 1st, 2001. Hmm, I won't be asking TDR to fix *my* date routines... ( Arthur C Clarke chose "2001" as the title of the book and film because it's the first year of the next century. ) [Moderator's Note: Clarke also said that the worldwide phone system would eliminate tolls on all calls anywhere in the world. I'm not sure how that would be paid for, but it's an interesting concept. Oh yes, is he referring to ME when he uses the term 'TDR' or the services of my company? :) Actually, that's why my domain name is 'TDR.COM' because I have used a login name of 'TDARCOS' for many years, and people started referring to me as TDR. The name stuck, so I decided to use it.] ------------------------------ Date: Wed, 17 Aug 1994 11:35:31 -0400 (EDT) From: Bradley White <bww+(a)transarc.com> To: Problem Reporting Service <PROBLEMS(a)tdr.com> Subject: Re: Six Digit Dates > Which date is earlier, 01/01/99 or 01/03/00? I would say 01/01/99. > What is the mathematical difference between 12/15/99 and > 01/03/00? About 99 years. I would say 19 days. If you are only going to use `00'-`99' to represent a year, you need to select an appropriate point of discontinuity. The choice is undoubtedly time and application dependent. 99->00 clearly isn't the best choice at the moment for almost all applications. [Moderator's Note: No it isn't, but I suspect many applications didn't take the effective year in mind when they were coded, but take the actual year. But from a mathematical standpoint chances are - unless the program was designed correctly in the first place - I'd figure a program would treat a date of 12/31/00 as earlier than 01/01/99. By 98 years and change.] ------------------------------ Date: Wed, 17 Aug 1994 14:59:00 -0400 From: Dan Astoorian <djast(a)utopia.druid.com> To: risks(a)csl.sri.com, PROBLEMS(a)tdr.com Subject: Re: Six Digit Dates >>From: Problem Reporting Service <PROBLEMS(a)TDR.COM> >>Newsgroups: tdr.problems >>Subject: 0026 - Exactly. What do we do? (Six Digit Dates) > >By coding the date into a character field, effectively in base 32, it >would be possible to encode a larger date and still only use 6 characters. >By encoding the year to use the letters of the alphabet, e.g. AA through >ZZ plus A0 through Z0, it is possible to cover more than 900 years, e.g. >start counting with 1400 through 2300, thus covering any date that could >have occurred during civilization. Rather pessimistic to assume that civilization will end before the year 2300, wouldn't you say? ;-) I'm sure it comes as a surprise to no one that this approach has been considered before. There are a number of problems with it. Given that with current dates, the year <x>9 is followed by <y>0, (for 0 <= x < 9 and y := x + 1), imposing an ordering which used the entire space of [0-9A-Z][0-9A-Z] would necessarily be a fairly complicated algorithm; in fact, I expect that any such ordering (allowing A-Z for the units digit of the year) would be unwieldy for a human troubleshooter to determine the real year from the encoding easily, and equally difficult for an implementor to get verifiably correct. Using alphabetic characters for the tens' digit would still buy a couple hundred years, though. However, any such "extension" to the storage encoding needs to be mapped to a readable date for the end users: Reports generated with dates of "Monday, January 3, 19A0" will not be acceptable (even if the report does not cause errors by being used as input to other software modules.) This is at least as large a problem as the storage issue. >One of the things that is necessary is to make programs expecting numbers >fail so that they can be changed. Programs that read these records will >have to expect both old and new format records, while programs that write >them should only output the new format. This assumes, of course, that the failure mode of a program which got a non-number when it expected a number will be reasonable; how valid is that assumption? I can easily imagine programs figuring the difference between the years 2000 and 1998 by the calculation "98" -> (('9'-'0') * 10) + 8 = (9 * 10) + 8 = 98 "A0" -> (('A'-'0') * 10) + 0 = (-47 * 10) + 0 = -470 "A0" - "98" = -470 - 98 = -568 years. (Of course, if the computation were performed in ASCII rather than EBCDIC the difference would only be +72 years.) We haven't even spoken of the issue of how dates will be communicated *between* machines which use 6-digit dates. >If you have better ideas on how to solve the six-digit problem, please >write back. Probably the most common suggested solution is to change the date-comparison algorithms to consider any date with a numerical value smaller than some threshold <N> to be a 21st-century date; eg., say that '50' means 2050, but '51' means 1951. This works if all the dates you want to represent are within a century of each other (and, of course, if the years wrap around from 99 to 00 smoothly, which isn't a given; what happens if you subtract 2 years from (20)01? Will you get "99", "-1", or something worse?) The other common suggestion is to add a separate 2-digit field for the century; as packed decimal this would require only one additional byte for each date represented in the record. There's no law that says that the century and the year need to be physically contiguous, so it may not be that difficult to find a couple of unused bytes somewhere in the data records to keep the extra information without requiring drastic database changes. This would also mean that many reporting programs would not need to be changed immediately, as they would continue to produce reports in the same form as before, assuming that they were not hard-coded to prepend "19" to the year. For many companies it is cost-effective to solve the *general* problem (the mainframe) rather than the specific problem (6-digit dates); the mainframes are expensive to maintain, and they won't be around forever. Cobol 85 compilers and online transaction processing systems are available for Unix. (At the RISK of Cantering: my employer sells a Unix OLTP system for COBOL users; for more information send mail to this address or to info(a)allross.com. 'Nuff said.) [Moderator's Note: How about 'mea culpa', 'mea maxima culpa' for a plea for mercy for me and my big mouth in not thinking about the way that came out. Or should I say, 'for me and my fat fingers?' :) '2399' was a reasonable alternative to 9999; my use of the term 'civilization' was pushing backward toward the earliest possible date that someone would have date references for. Since Columbus landed on Cuba in 1492 I doubt we need to worry about earlier dates. (Yes, I know about the Vikings being in North America in the 1100s, but they didn't publicize it very well.) Adding space to some data files is not an option in the near future in some installations. I think TRW, for example, has something like 180 million credit reports on file. If each report has 10 entries that use dates, that's 3 billion bytes of disk space that have to be added just to stretch these files by a measly 2 bytes. Then, you have to go back and edit every single program that uses those files to tell them that the file is now two bytes longer in every record. Many of these files are on old DASD which means the files would require migration to expand them and thus would raise all sorts of problems. Personally I think that if programs have to be changed to fix this problem - and they do - the change should be as light as possible and the minimum necessary to fix it, considering how fragile many programs are. Changing a program to add a means to recalculate the date is probably less of a change than expanding every record definition and reference to the file data to add two bytes. In the long run this is the correct answer, e.g. that the file data should support 8 digit dates, and hopefully as systems move off those old mainframe dinosaurs that served us so well, the data files will be updated. Some might say 1700 might have been far enough back. Consider that here in Maryland a local jurisdiction will celebrate a special anniversary in three years. As it says on the freeway signs: Welcome to Prince Georges' County, Established 1697. As far as 2399 is concerned, I personally, do not expect this civilization to last even that long. I will be surprized if the current civilization lasts another 50 years; whether things get better or worse is a matter of taste; explaining my reasons why is too complicated an issue to do in less than a complete issue and is way off the subject here. However, the point has been raised so I will discuss it in a later issue. ] ------------------------------ Date: Wed, 17 Aug 94 14:33:55 -0500 From: Steve Peltz <peltz(a)cerl.uiuc.edu> To: PROBLEMS(a)tdr.com Subject: Re: Six Digit Dates Re: Article forwarded to RISKS Instead of doing funny things with the year field, it seems much easier (and easier to deal with BCD fields) to play with the month. Add 12 to the month for the next century. Add 12 more for the century after. That should hold us for about 7 more centuries into the future. If that isn't enough (and if a program sticks around through 20 years of computer evolution, it will probably last 800), add 33 to the day field and go through 8 more centuries. At that point, it is probably time to put your foot down and demand that the old programs be completely re-written (but at least you still have another 8 centuries to go before they have to be completed, since you can still add another 33 to the day field). [Moderator's note: 'If a program sticks around through 20 years of computer evolution, it will probably last 800.' That statement probably needs to be recorded for posterity. This solution sounds like an even better solution than mine. So far, this sounds like the best 'interim' solution to the problem. 'Interim' meaning until what the previous two messages stated; make the data files two bytes bigger for every date field. Preferably making the addition contiguous to and part of the date.] ------------------------------ Date: Thu, 18 Aug 1994 12:32:37 -0500 (EDT) From: Jeff Jonas <jeffj(a)telerate.com> To: problems-request(a)tdr.com Subject: Re: Six Digit Dates I just read your posting in the RISKS digest about the 6 digit year problem. Unfortunately, most COBOL programmers may have used packed-decimal coding or BCD for the year, where there's really no tolerance for digits other than 0-9 despite 4 bits per digit. Even if you could force values >9 to the date, the arithmetic routines normalize the year back to values 0-9. I'm fortunate to work in the Unix environment where the native date format is in seconds since Jan 1, 1970 so that reaches well into 2000 before wrapping. [Moderator's Note: And VMS (the operating system for VAX and Alpha processors) goes back to the 1800s as does the $HOROLOG function of the MUMPS / M Programming Language.] ------------------------------ Date: Thu, 18 Aug 94 10:46:42 edt From: Mike_Perry(a)dge.ceo.dg.com To: problems-request(a)tdr.com Subject: Re: Six Digit Dates Message: I saw your posting via RISKS DIGEST. I hope your worst fears aren't realised, but things ARE going to go bad, that's for sure, and I'd be surprised if they aren't already, with calculations that look forward in time - as you say, it's less than 6 years away. I encountered this (type of) problem several years ago with a project planning system that used absolute week numbers based on week1=date_the_system_went_live. 3 digits were allowed for week numbers, and sure enough, some 14 years later, a project with a 5-6 year timespan tripped over to week 0......... BTW - the last day of this century, (and this millenium) is December 31, 2000, not 1999. Regds., Mike ------------------------------ Date: Thu, 18 Aug 1994 12:17:25 -0700 From: Brian Kantor <brian(a)nothing.ucsd.edu> To: problems-request(a)tdr.com Subject: Re: Six Digit Dates no doubt a million other people have written to point out that the last day of the century is Dec 31, 2000, not 1999. The rest of your note is well-taken, though. - Brian ------------------------------ Date: Fri, 19 Aug 94 16:46 CDT From: "William G. Lederer" <wgl(a)mcs.com> To: PROBLEMS(a)tdr.com Subject: Re: Six Digit Dates Just one note on your otherwise fine and informative article. The century actually does not end until the end of the day on December 31, 2000. I predict, however, that journalists and the like will also get this one wrong. [Moderator's Note: I fully support your prediction. :) ] ------------------------------ Date: Mon, 22 Aug 1994 11:54:25 -0600 From: Thomas McNeill <TGM(a)wordperfect.com> To: PROBLEMS(a)tdr.com Subject: Re: Six Digit Dates In almost all cases it will not be necessary to change to 8 digit dates, at least not immediately. All you have to do is change the routines that calculate the difference between two dates. In those routines, add 2000 to years less than 50 to arrive at the full year, and add 1900 to years greater than or equal to 50. This will gives us approximately 50 years of breathing room to implement the real fix, which is to go to 8 digit dates. Changing the encoding scheme in the disk files so that 6 bytes encodes a larger range of dates would require not only recoding the applications, but also making passes through all the files to change the encoding scheme. [Moderator's Note: This is a good answer to the message sent to me privately on the subject, which appears as a summary as the last item in this digest, two entries below. ] ------------------------------ Date: Wed, 24 Aug 94 15:59:09 PDT From: Russell Brand <brand(a)reasoning.com> To: PROBLEMS(a)tdr.com Subject: Re: Six Digit Dates I am one of the developers of a program understanding & re-engineering tool called Refine/COBOL [tm]. Some of the most interesting applications of our tool have been to modify legacy COBOL systems so as allow them to be continue to be used past the year 2000. Some of my users started hitting the problem in 1993 because as their budgetting offices had 7 year projects. For some of these firms, they are using the program analysis tools to automatically find things that look like dates, and modify comparisions and differences such that 00-49 represents 2000-2049 rather than 1900-1949. While there was some discussion of using other encoding (trating the high order digit as HEX rather than decimal) and making somewhat different set of conversions. I would be interesting in hear other approaches that have been attempted. Some description of my groups work can be found in the May 1994 issue of _Communications of the ACM_ or on our world wide web server www.reasoning.com /Russell brand(a)reasoning.com ------------------------------ Date: Fri, 26 Aug 1994 08:21:55 -0400 (EDT) From: Paul Robinson <PAUL(a)TDR.COM> Subject: Re: Six Digit Dates From: Paul Robinson <PAUL(a)TDR.COM> Organization: Tansin A. Darcos & Company, Silver Spring, MD USA ----- On Thu, 25 Aug 1994, "someone" wrote to say the following, which has been paraphrased: Arthur C Clarke's book "The Ghost of the Grand Banks" discusses this, and in the book a character writes a benign computer virus whose task is to change routines using 2 digit years to 4 digit ones. Interesting concept. One of the problems is huge databases; some of them are currently, shall we say "maxxed out" on multipack systems in terms of the amount of space used; to add any material to the files would require either shutting down the system and rebuilding the database, or running a specialized conversion program simultaneously with the applications so that the conversion program is doing a rebuild to add the additional space to the file as a new file, while the applications in use are running, plus logging their transactions so that their updates can be carried across. Either is not a pleasant idea. Beyond that, let's say a company has, say, 125 million current transaction records covering such things as last 90 days of payments, charges, etc, e.g. a bank with, say, 2 million credit cards, loans and depositors, an average of perhaps 50-60 transaction lines per customer. To add a measly two bytes to just update current transaction information means adding a whopping 250 million bytes of storage just for this. If they have even longer data retention periods (let's say it's more than 90 days) the disk drive requirements are somewhat more. Mainframes aren't PCs. You can't just simply add another disk drive which costs about $500 for 1gb. First, mainframe drives are more expensive for a variety of reasons including multiple access. Next, you have to add the disk space (which may require updating operating system tables), then migrate the file records over to the new pack, while deleting the old ones in order to free up space, unless you want replicated copies of the database at the same time, which could get expensive. Assuming those 125 million current transaction records use about 100 bytes each, this means the bank has 12.5 thousand million (12.5 billion) bytes of current transaction data. That would be a lot of extra disk space and even converting is going to be a lot of I/O and will take time. I am not convinced of the benefits suggested by your cure. To make those modifications will require amending many thousands of lines of code. Exactly. And we will have to have automated tools; the job is too large to do manually. I'm thinking of creating some. (I could use the money, too. :) ). So why not simply expand to 4 digit dates at the same time, which would be stable for 8,000 more years until we have to change the date system anyway... Eventually that will have to be done. But one of the things to remember is that because many computer systems are extremely fragile, that we want any change to be (1) as simple as possible and (2) do only the minimum necessary to avoid damaging the system as running. They used to tell something similar to this to physicians (in relating to an attempt by programmers not to make a change that damages the running application), "First, do no harm." Also, we should try to make the changes so that if we can, we prevent the occurrence of "feature interactions". A "feature interaction" is when doing one thing causes a change or an indeterminant state in another, e.g. if you have both call waiting (allowing you to take two calls on your line) and hunt group (causing calls coming into your line to transfer to another line) both on the same line, when the second call comes in, does call waiting kick in first (allowing the second call on the line) or does hunt group kick in first (transferring the second call)? It depends on how the software is set up, which means that using both call waiting and hunt group on the same line causes a "feature interaction." [Moderator's Note: I think it's clear, long term we will have to code 8-digit dates into files, and if we use something akin to the suggestion to change the day of the month or the day of the year, we can stave off major code changes until these applications migrate to servers and such and it solves the problem for us, as long as the new files have the space in them. Which of these is the acceptable solution is a matter of taste; I like the changing of the day or month fields so that programs that don't change them will show up with bad dates in display fields. Question to consider: how much "free" space should be left in a data file and when should it be rebuilt? Here's a suggestion; any database should initially provide 20% of the space in each record for future use, e.g. in a record that needs 100 bytes, the record should be 120 bytes (or make it 128 to be even with a power of 2 since it's close) and then the files should be re-epanded when the amount of free space drops below 10%, so that you don't have this kind of crunch again. This may seem ridiculously high and wasteful, but how wasteful is it to have to stretch and squeeze to add something that has to be done that had the resources been left there ahead of time, would not be a problem? Harvey Mackay, in his book "Swim With the Sharks" says that you should "dig your well before you are thirsty.". I think the comment is appropriate here. Provide the space in advance, before it's needed and finding the space later is less of a problem. Fixing the 6-digit problem would have been trivial if this had been done. Yes, yes, I know disk space was very expensive a while back; I remember about 12 years ago when one of my bosses was trying to Jew down the supplier of a disk pack to reduce the price of a 100 meg pack from $700 to $600. This is for the removable pack alone, the disk drive was something like $12,000. In any case, the price of disk space should no longer be as much of a problem. (Then again, some places would have no trouble paying a consultant $5,000 to tell them the information I supplied in issue #26 and this issue, but would take forever to raise $2,000 if one of their employees wanted to order a couple GB more disk space.) Am I wrong, or are there a lot of systems that don't have the space to add two bytes to each record in a major, company-critical data base because the record *is* "maxxed out" and there is no room left in the records for additions without rebuilding the database, which is seen to be about as much fun as anesthesia-less root-canal surgery? You can write me privately if you don't want to wash your dirty laundry in public.] ------------------------------ End of Problems Digest V94 Issue #27 ************************************

1 0

tzdata94f.tar.gz
by ado Aug. 20, 1994

Aug. 20, 1994

The file tzdata94f.tar.gz in the ~ftp/pub directory on elsie.nci.nih.gov reflects (with thanks!) the latest data updates from Paul Eggert. --ado

1 0

7th EC directive on summer time
by Peter Ilieve Aug. 18, 1994

Aug. 18, 1994

I was just sitting down to type this in when Paul Eggert's mail with all the suggested changes arrived. I now have the text of the 7th EC directive on summer time arrangements (94/21/EC), which was approved on 30 May. This was a few days before I spoke to the EC Information Office in Edinburgh back in June, but they didn't know about it then, which is disappointing. It confirms the dates set out in the Common Position document I reported in June. The major changes from existing practice are that 1995 will be the last year that the UK and Eire finish on a different date from everyone else, and the common end date from 1996 onwards will be the last Sunday in October. The dates again, taken from my last mail: Year Start End End (UK & Eire, 1995 only) (rule) (last Sun) (last Sun) (4th Sun) 1995 26 March 24 September 22 October 1996 31 March 27 October 1997 30 March 26 October I agree with the change that Paul has suggested, of having a rule of Oct Sun>=22 for 1990--95, rather than only for 1995. There is no sign of a UK Summer Time Order yet. Our parliament is on holiday until about October so it won't appear until then I guess. They didn't go into recess until about two weeks ago so they had plenty of time since 30 May to get organised. It is almost inconceivable that the UK Order wouldn't follow these dates, as the rest of the EU has effectively moved to our ending date, but anything is possible with politicians. Austria has already voted in a referendum to join the EU on 1 Jan 95 and it looks almost certain that Finland, Norway and Sweden will as well. I seem to have lost my up-to-date tzdata files so I don't know if they already have these countries using EU rules, but they will from 1995. Peter Ilieve peter(a)memex.co.uk

1 0

proposed changes to tz data
by eggert＠twinsun.com Aug. 18, 1994

Aug. 18, 1994

I went through all the messages to the tz list in the past weeks plus a few notes I had made to myself, and came up with the following proposed changes to the tz data. Aside from comments, the changes are: * Adjust the Australia/Adelaide rule to reflect known behavior since 1990 reported by John Connolly, Robert Elz, and Bradley White. * Adjust Asia/Novosibirsk to reflect that it switched time zones in March, as reported by Stanislaw Kuzikowski. Add a new zone Asia/Tomsk, since Tomsk did not switch and we need a Russian city that is +0700. * Change `Asia/Almaty' to `Asia/Alma-Ata'. This is in keeping with the policy of using traditional English names. And even the _Economist_, which brought up the name `Almaty' in the first place, has gone back to calling that city `Alma-Ata'. * Repair LMT typos for Atlantic/Faeroe, Europe/Vaduz, Pacific/Enderbury, and Pacific/Wallis (thanks to Gwillim Law); and for Europe/London (thanks to Peter Ilieve). * Include two more historical events where the clock changed by 24 hours, one in Asia/Manila in 1844, the other in Pacific/Samoa in 1879. I still don't know the details about America/Anchorage in 1867. The most important changes to commentary are notes under GB-Eire and M-Eur about the proposed 7th EU daylight savings time directive; thanks to Peter Ilieve for this. A simple switch of commentary and code can be done if the EU proposal is adopted. diff -c ty/asia tz/asia *** ty/asia Sat Jun 4 10:12:51 1994 --- tz/asia Thu Aug 18 09:36:57 1994 *************** *** 4,10 **** # go ahead and edit the file (and please send any changes to # tz(a)elsie.nci.nih.gov for general use in the future). ! # From Paul Eggert <eggert(a)twinsun.com> (November 18, 1993): # # A good source for time zone historical data outside the U.S. is # Thomas G. Shanks, The International Atlas (3rd edition), --- 4,10 ---- # go ahead and edit the file (and please send any changes to # tz(a)elsie.nci.nih.gov for general use in the future). ! # From Paul Eggert <eggert(a)twinsun.com> (August 18, 1994): # # A good source for time zone historical data outside the U.S. is # Thomas G. Shanks, The International Atlas (3rd edition), *************** *** 15,20 **** --- 15,24 ---- # Whitman Publishing Co, 2 Niagara Av, Ealing, London (undated), which # I found in the UCLA library. # + # A reliable and entertaining source about time zones is + # Derek Howse, Greenwich time and the discovery of the longitude, + # Oxford University Press (1980). + # # I invented the abbreviations marked `*' in the following table; # the rest are from earlier versions of this file, or from other sources. # Corrections are welcome! *************** *** 287,293 **** 5:30 - IST 1942 Sep 5:30 1:00 IST 1945 Oct 15 5:30 - IST ! # The following are like India/Calcutta: # Andaman Is # Lakshadweep (Laccadive, Minicoy and Amindivi Is) # Nicobar Is --- 291,297 ---- 5:30 - IST 1942 Sep 5:30 1:00 IST 1945 Oct 15 5:30 - IST ! # The following are like Asia/Calcutta: # Andaman Is # Lakshadweep (Laccadive, Minicoy and Amindivi Is) # Nicobar Is *************** *** 509,519 **** 2:00 Jordan EET%s # Kazakhstan - # From Paul Eggert <eggert(a)twinsun.com> (November 18, 1993): - # Before 1993, Almaty was known by its Russian name ``Alma-Ata''. # From Shanks (1991): # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Asia/Almaty 5:07:48 - LMT 1924 May 2 5:00 - TSK 1957 Mar 6:00 Russia TS%s --- 513,521 ---- 2:00 Jordan EET%s # Kazakhstan # From Shanks (1991): # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Asia/Alma-Ata 5:07:48 - LMT 1924 May 2 5:00 - TSK 1957 Mar 6:00 Russia TS%s *************** *** 673,678 **** --- 675,682 ---- # This will undoubtedly change soon. # Philippines + # Howse writes (p 162) that until 1844 the Philippines kept American date. + # The rest of this data is from Shanks. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Phil 1899 only - May 11 0:00 0 S Rule Phil 1936 only - Nov 1 0:00 1:00 D *************** *** 682,688 **** Rule Phil 1978 only - Mar 22 0:00 1:00 D Rule Phil 1978 only - Sep 21 0:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Asia/Manila 8:04:00 - LMT 1899 May 11 8:00 Phil P%sT 1942 May 9:00 - JST 1944 Nov 8:00 Phil P%sT --- 686,693 ---- Rule Phil 1978 only - Mar 22 0:00 1:00 D Rule Phil 1978 only - Sep 21 0:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Asia/Manila -15:56:00 - LMT 1844 ! 8:04:00 - LMT 1899 May 11 8:00 Phil P%sT 1942 May 9:00 - JST 1944 Nov 8:00 Phil P%sT diff -c ty/australasia tz/australasia *** ty/australasia Mon Feb 7 06:57:49 1994 --- tz/australasia Thu Aug 18 09:07:12 1994 *************** *** 52,58 **** Rule AS 1972 only - Feb 27 3:00 0 - Rule AS 1973 1985 - Mar Sun>=1 3:00 0 - Rule AS 1986 1989 - Mar Sun>=15 3:00 0 - ! Rule AS 1990 max even Mar Sun>=22 3:00 0 - Rule AS 1990 max odd Mar Sun>=1 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Adelaide 9:14:20 - LMT 1895 Feb --- 52,58 ---- Rule AS 1972 only - Feb 27 3:00 0 - Rule AS 1973 1985 - Mar Sun>=1 3:00 0 - Rule AS 1986 1989 - Mar Sun>=15 3:00 0 - ! Rule AS 1990 max even Mar Sun>=18 3:00 0 - Rule AS 1990 max odd Mar Sun>=1 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Adelaide 9:14:20 - LMT 1895 Feb *************** *** 181,187 **** # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Pacific/Tarawa 11:32:04 - LMT 1901 # Bairiki 12:00 - NZST ! Zone Pacific/Enderbury -12:35:40 - LMT 1901 -12:00 - KJT 1979 Oct -11:00 - SST Zone Pacific/Kiritimati -10:29:20 - LMT 1901 --- 181,187 ---- # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Pacific/Tarawa 11:32:04 - LMT 1901 # Bairiki 12:00 - NZST ! Zone Pacific/Enderbury -11:24:20 - LMT 1901 -12:00 - KJT 1979 Oct -11:00 - SST Zone Pacific/Kiritimati -10:29:20 - LMT 1901 *************** *** 330,336 **** # Wallis and Futuna # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Pacific/Wallis 11:44:40 - LMT 1901 12:00 - NZST # Western Samoa --- 330,336 ---- # Wallis and Futuna # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Pacific/Wallis 12:15:20 - LMT 1901 12:00 - NZST # Western Samoa *************** *** 344,354 **** # go ahead and edit the file (and please send any changes to # tz(a)elsie.nci.nih.gov for general use in the future). ! # From Paul Eggert <eggert(a)twinsun.com> (November 18, 1993): # A good source for time zone historical data outside the U.S. is # Thomas G. Shanks, The International Atlas (3rd edition), # San Diego: ACS Publications, Inc. (1991). ! # Except where noted below, it is the source for the data above. # # I invented the abbreviations marked `*' in the following table; # the rest are from earlier versions of this file, or from other sources. --- 344,362 ---- # go ahead and edit the file (and please send any changes to # tz(a)elsie.nci.nih.gov for general use in the future). ! # From Paul Eggert <eggert(a)twinsun.com> (August 18, 1994): # A good source for time zone historical data outside the U.S. is # Thomas G. Shanks, The International Atlas (3rd edition), # San Diego: ACS Publications, Inc. (1991). ! # Except where noted, it is the source for the data above. ! # ! # Another source occasionally used is Edward W. Whitman, World Time Differences, ! # Whitman Publishing Co, 2 Niagara Av, Ealing, London (undated), which ! # I found in the UCLA library. ! # ! # A reliable and entertaining source about time zones is ! # Derek Howse, Greenwich time and the discovery of the longitude, ! # Oxford University Press (1980). # # I invented the abbreviations marked `*' in the following table; # the rest are from earlier versions of this file, or from other sources. *************** *** 547,552 **** --- 555,570 ---- # numbered year (from 1990). That's when the Adelaide Festival # is on... + # From Robert Elz (March 16, 1992, 00:57:07 +1000): + # DST didn't end in Adelaide today (yesterday).... + # But whether it's "4th Sunday" or "2nd last Sunday" I have no idea whatever... + # (it's just as likely to be "the Sunday we pick for this year"...). + + # From Bradley White (April 11, 1994): + # If Sun, 15 March, 1992 was at +1030 as kre asserts, but yet Sun, 20 March, + # 1994 was at +0930 as John Connolly's customer seems to assert, then I can + # only conclude that the actual rule is more complicated.... + # Australia/Tasmania # From Bradley White (March 4, 1991): *************** *** 706,711 **** --- 724,735 ---- ############################################################################### + # Fiji + + # Howse writes (p 162) that in 1879 the British governor of Fiji + # enacted an ordinance standardizing the islands on +12:00. + # Perhaps it didn't take. We go with Shanks's more precise date in 1915. + # Kwajalein # In comp.risks 14.87 (26 August 1993), Peter Neumann writes: *************** *** 713,715 **** --- 737,746 ---- # August 20, 1993. Thursday night at midnight Kwajalein switched sides with # respect to the International Date Line, to rejoin its fellow islands, # going from 11:59 p.m. Thursday to 12:00 m. Saturday in a blink. + + # Pacific Islands Trust Territories + + # Howse writes (p 162) ``The Spaniards, on the other hand, reached the + # Philippines and the Ladrones from America,'' and implies that the Ladrones + # (now called the Marianas) kept American date for quite some time. + # Ignore this for now, as we have no hard data. See also Asia/Manila. diff -c ty/europe tz/europe *** ty/europe Sat Jun 4 10:12:52 1994 --- tz/europe Thu Aug 18 10:17:10 1994 *************** *** 35,41 **** # 4:00 KSK KSD Kuybyshev* # 5:00 ESK ESD Yekaterinburg* # 6:00 OSK OSD Omsk* ! # 7:00 NSK NSD Novosibirsk # 8:00 ISK ISD Irkutsk* # 9:00 YSK YSD Yakutsk* # 10:00 VSK VSD Vladivostok* --- 35,42 ---- # 4:00 KSK KSD Kuybyshev* # 5:00 ESK ESD Yekaterinburg* # 6:00 OSK OSD Omsk* ! # 6:00 NSK NSD Novosibirsk (was 7:00 until 1994) ! # 7:00 TSK TSD Tomsk* # 8:00 ISK ISD Irkutsk* # 9:00 YSK YSD Yakutsk* # 10:00 VSK VSD Vladivostok* *************** *** 56,61 **** --- 57,83 ---- # United Kingdom + # From Peter Ilieve <peter(a)memex.co.uk> (July 6, 1994): + # + # On 17 Jan 1994 the Independent, a UK quality newspaper, had a piece about + # historical vistas along the Thames in west London. There was a photo + # and a sketch map showing some of the sightlines involved. One paragraph + # of the text said: + # + # `An old stone obelisk marking a forgotten terrestrial meridian stands + # beside the river at Kew. In the 18th century, before time and longditude + # was standardised by the Royal Observatory in Greenwich, scholars observed + # this stone and the movement of stars from Kew Observatory nearby. They + # made their calculations and set the time for the Horse Guards and Parliament, + # but now the stone is obscured by scrubwood and can only be seen by walking + # along the towpath within a few yards of it.' + # + # I have a one inch to one mile map of London and my estimate of the stone's + # position is 51 deg. 28' 30" N, 0 deg. 18' 45" W. The longditude should + # be within about +-2". The Ordnance Survey grid reference is TQ172761. + # + # [This yields GMTOFF = -0:01:15 for London LMT in the 18th century.] + # From Paul Eggert <eggert(a)twinsun.com> (November 18, 1993): # # Howse writes that Britain was the first country to use standard time. *************** *** 548,553 **** --- 570,597 ---- # 1993 28 Mar 24 Oct fixed # 1994 27 Mar 23 Oct fixed + # From Peter Ilieve <peter(a)memex.co.uk> (June 8, 1994): + # The European Union bureaucracy has edged a step closer to a 7th Directive + # on summer-time arrangements. I have the text of a Common Position + # (EC No 9/94) and a statement of the Council's reasons dated 4 March 94, + # reported in the Official Journal of the EC, No. C 137/38--41.... + # The dates again: + # Year Start End End (UK & Eire, 1995 only) + # (rule) (last Sun) (last Sun) (4th Sun) + # 1995 26 March 24 September 22 October + # 1996 31 March 27 October + # 1997 30 March 26 October + + # From Peter Ilieve <peter(a)memex.co.uk> (March 28, 1994): + # The UK/Eire end date of 22 October [1995] conflicts with your current rule of + # Oct Sun>=23, and the historical UK formula of Sun after 4th Sat. + # The last time 4th Sun and Sun after 4th Sat differed was in 1989, + # when 29 October was used. That year was covered by a UK Summer Time Order + # for only a single year and it looks as though there was a matching 4th EC + # directive for just this year. I don't have the text of the 5th EC + # directive (for 1990--92) but my guess would be it said 4th Sun. + # To maintain strict historical accuracy you could start a new UK ending rule + # of Oct Sun>=22 in 1990. # From Paul Eggert <eggert(a)twinsun.com> (November 18, 1993): # *************** *** 652,660 **** # Current rules Rule GB-Eire 1981 max - Mar lastSun 1:00s 1:00 BST Rule GB-Eire 1981 max - Oct Sun>=23 1:00s 0 GMT # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Europe/London -0:00:37 - LMT 1847 Sep 22 0:00 GB-Eire %s 1968 Feb 18 2:00 1:00 - BST 1971 Oct 31 2:00 0:00 GB-Eire %s --- 696,708 ---- # Current rules Rule GB-Eire 1981 max - Mar lastSun 1:00s 1:00 BST Rule GB-Eire 1981 max - Oct Sun>=23 1:00s 0 GMT + # Under the 7th EU proposal, replace the above line with the following three: + #Rule GB-Eire 1981 1989 - Oct Sun>=23 1:00s 0 GMT + #Rule GB-Eire 1990 1995 - Oct Sun>=22 1:00s 0 GMT + #Rule GB-Eire 1996 max - Oct lastSun 1:00s 0 GMT # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Europe/London -0:01:15 - LMT 1847 Sep 22 0:00 GB-Eire %s 1968 Feb 18 2:00 1:00 - BST 1971 Oct 31 2:00 0:00 GB-Eire %s *************** *** 708,713 **** --- 756,764 ---- Rule M-Eur 1977 only - Sep lastSun 2:00s 0 - Rule M-Eur 1978 only - Oct 1 2:00s 0 - Rule M-Eur 1979 max - Sep lastSun 2:00s 0 - + # Under the 7th EU proposal, replace the above line with the following two: + #Rule M-Eur 1979 1995 - Sep lastSun 2:00s 0 - + #Rule M-Eur 1996 max - Oct lastSun 2:00s 0 - Rule M-Eur 1981 max - Mar lastSun 2:00s 1:00 " DST" Rule E-Eur 1981 max - Mar lastSun 3:00s 1:00 " DST" *************** *** 945,951 **** 1:00 M-Eur MET%s 1945 Apr 2 2:00 1:00 Denmark MET%s 1980 Apr 6 2:00 1:00 M-Eur MET%s ! Zone Atlantic/Faeroe 0:27:04 - LMT 1908 Jan 11 # Torshavn 0:00 - WET 1981 Mar 29 1:00 0:00 W-Eur WET%s Zone America/Scoresbysund -1:29:00 - LMT 1916 Jul 28 --- 996,1002 ---- 1:00 M-Eur MET%s 1945 Apr 2 2:00 1:00 Denmark MET%s 1980 Apr 6 2:00 1:00 M-Eur MET%s ! Zone Atlantic/Faeroe -0:27:04 - LMT 1908 Jan 11 # Torshavn 0:00 - WET 1981 Mar 29 1:00 0:00 W-Eur WET%s Zone America/Scoresbysund -1:29:00 - LMT 1916 Jul 28 *************** *** 1269,1275 **** # Liechtenstein # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Europe/Vaduz 0:30:04 - LMT 1894 Jun 1:00 - MET 1981 Mar 29 2:00 1:00 M-Eur MET%s --- 1320,1326 ---- # Liechtenstein # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Europe/Vaduz 0:38:04 - LMT 1894 Jun 1:00 - MET 1981 Mar 29 2:00 1:00 M-Eur MET%s *************** *** 1618,1629 **** 5:00 1:00 OSD 1991 Sep 29 2:00s 5:00 - OSK 1992 Jan 19 2:00s 6:00 Russia OS%s Zone Asia/Novosibirsk 5:31:40 - LMT 1924 May 2 6:00 - NSK 1957 Mar 7:00 Russia NS%s 1991 Mar 31 2:00s 6:00 1:00 NSD 1991 Sep 29 2:00s 6:00 - NSK 1992 Jan 19 2:00s ! 7:00 Russia NS%s Zone Asia/Irkutsk 6:57:20 - LMT 1880 6:57 - LST 1924 May 2 7:00 - ISK 1957 Mar --- 1669,1694 ---- 5:00 1:00 OSD 1991 Sep 29 2:00s 5:00 - OSK 1992 Jan 19 2:00s 6:00 Russia OS%s + # From Stanislaw A. Kuzikowski <S.A.Kuz(a)iae.nsk.su> (June 29, 1994): + # But now it is some months since Novosibirsk is 3 hours ahead of Moscow! + # I do not know why they have decided to make this change; + # as far as I remember it was done exactly during winter->summer switching + # so we (Novosibirsk) simply did not switch. + # Tomsk is still 4 hours ahead of Moscow. Zone Asia/Novosibirsk 5:31:40 - LMT 1924 May 2 6:00 - NSK 1957 Mar 7:00 Russia NS%s 1991 Mar 31 2:00s 6:00 1:00 NSD 1991 Sep 29 2:00s 6:00 - NSK 1992 Jan 19 2:00s ! 7:00 Russia NS%s 1994 Mar 27 2:00s ! 6:00 1:00 NSD 1994 Sep 25 2:00s ! 6:00 Russia NS%s ! Zone Asia/Tomsk 5:39:52 - LMT 1924 May 2 ! 6:00 - TSK 1957 Mar ! 7:00 Russia TS%s 1991 Mar 31 2:00s ! 6:00 1:00 TSD 1991 Sep 29 2:00s ! 6:00 - TSK 1992 Jan 19 2:00s ! 7:00 Russia TS%s Zone Asia/Irkutsk 6:57:20 - LMT 1880 6:57 - LST 1924 May 2 7:00 - ISK 1957 Mar *************** *** 1725,1731 **** Rule Spain 1977 1978 - Apr 2 23:00 1:00 " DST" Rule Spain 1978 only - Oct 1 1:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Europe/Madrid 0:14:44 - LMT 1901 0:00 Spain WET%s 1946 Sep 30 1:00 Spain MET%s 1979 Apr 1 2:00 1:00 M-Eur MET%s --- 1790,1796 ---- Rule Spain 1977 1978 - Apr 2 23:00 1:00 " DST" Rule Spain 1978 only - Oct 1 1:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Europe/Madrid -0:14:44 - LMT 1901 0:00 Spain WET%s 1946 Sep 30 1:00 Spain MET%s 1979 Apr 1 2:00 1:00 M-Eur MET%s diff -c ty/northamerica tz/northamerica *** ty/northamerica Sat Jun 4 10:12:51 1994 --- tz/northamerica Wed Aug 17 23:23:49 1994 *************** *** 5,10 **** --- 5,15 ---- # go ahead and edit the file (and please send any changes to # tz(a)elsie.nci.nih.gov for general use in the future). + # From Paul Eggert <eggert(a)twinsun.com> (August 17, 1994): + # A reliable and entertaining source about time zones is + # Derek Howse, Greenwich time and the discovery of the longitude, + # Oxford University Press (1980). + ############################################################################### # United States *************** *** 106,111 **** --- 111,121 ---- # Samoa standard time # The law doesn't give abbreviations. + # From Paul Eggert <eggert(a)twinsun.com> (August 16, 1994): + # Howse writes that Alaska switched from the Julian to the Gregorian calendar, + # and from east-of-GMT to west-of-GMT days, in 1867 when the US purchased it + # from Russia. We don't have this data pinned down yet, though. + # Easy stuff first--including Alaska, where we ignore history (since we # can't tell if we should give Yukon time or Alaska-Hawaii time for "old" # times). *************** *** 148,155 **** -5:00 US E%sT # Samoa just changes names. No DST, per Naval Observatory. ! Zone Pacific/Samoa -11:22:48 - LMT 1911 -11:30 - SST 1950 -11:00 - NST 1967 Apr # N=Nome -11:00 - BST 1983 Nov 30 # B=Bering --- 158,171 ---- -5:00 US E%sT # Samoa just changes names. No DST, per Naval Observatory. + # + # Howse writes that in 1879 the King of Samoa decided to change + # ``the date in his kingdom from the Antipodean to the American system, + # ordaining -- by a masterpiece of diplomatic flattery -- that + # the Fourth of July should be celebrated twice in that year.'' ! Zone Pacific/Samoa 12:37:12 - LMT 1879 Jul 5 ! -11:22:48 - LMT 1911 -11:30 - SST 1950 -11:00 - NST 1967 Apr # N=Nome -11:00 - BST 1983 Nov 30 # B=Bering

1 0

FYI: What do we do? (Six Digit Dates)
by Monty Solomon Aug. 17, 1994

Aug. 17, 1994

Begin forwarded message: Date: Fri, 11 Aug 1994 23:00:58 -0500 (EST) Newsgroups: tdr.problems From: Problem Reporting Service <PROBLEMS(a)tdr.com> Organization: Tansin A. Darcos & Company, Silver Spring MD USA Errors-To: PROBLEM-ERRORS(a)tdr.com Subject: 0026 - Exactly. What do we do? (Six Digit Dates) To: Recipients of list Problems <PROBLEMS(a)tdr.com> Please excuse the long delay between the prior posting and this one, I have been busy with a number of very critical issues unrelated to the posting below. I also didn't want to bother simply raising this issue - it's been raised many times before - and simply offer no solution as everyone else before, because all of them seems to have been unable to offer one before. I've been trying to think of a way to solve the problem. I - and probably many of you - have been trying to figure out what to do about it. I might have *a* solution. At the end of the movie of Dr. Michael Chrichton's "The Andromeda Strain" in a congressional hearing a Senator asks Dr. Stone what they can do if another biological emergency occurs. "What do we do then?" he asks. "Exactly, " responds Dr. Stone, "What do we do?" The problem is the issue of six-digit dates and the turn of the century, now less than six years away. The problem is probably not as bad as it was, because with the introduction of IBM PCs which support dates past the year 2100, the issue isn't a problem except to the extent of programs that still use six-digit dates. Some of you might not understand why this is a serious issue. I'll explain. Much software which is still in use - especially on mainframes - was written ten, fifteen, even twenty years ago for use in the solving of current problems at that time. Some of that software survives, even twenty years later. As I once pointed out in a posting on the newsgroup alt.cobol, a large company might have a massive 2,000,000 line cobol program with 500 modules that requires 50 programmers for its constant maintenance, care and feeding, and that over the years the company has probably spent in excess of fifteen million dollars. These applications are the "bet the company" applications that are used every day to keep it in business. They are the "crown jewels" that if anything goes wrong with the application, the company might actually go into Chapter 11 or suffer massive customer backlash. These applications cannot be rewritten because it would be too expensive, and the company can't afford to be without them. Thus, unless something happens to encourage the company to change its systems, they will continue running these old, maintenance-heavy applications, even five or ten years from now. In some cases, the program is so huge and so complicated nobody knows everything it does; it is beyond the capacity of any one person to know every function and interface and module. Therefore it can't be said with certainty what the different sections are doing with each other. Thus finding where things are happening can be frustratingly difficult. Which comes to the issue at hand. Many of these programs were written to use dates which are six digits in length. Three days from now it will be August 14, 1994. You can write that as 08/14/94 or 14/8/94 depending on which way your system codes dates. (I wanted to avoid confusion, because 8/11 or 11/8 could be referring to August 11 or November 8, but 8/14 or 14/8 as a date cannot be mistaken for anything else.) Figuring out the difference between 8/14/94 and 8/15/94 is no problem, and figuring out that 8/13/95 is after 8/14/94 is also no problem. The last date of this century is Friday, December 31, 1999. 12/31/99. Want to tell me what the next date after that is? Saturday, January 1, 2000. 01/01/00. Which date is earlier, 01/01/99 or 01/03/00? What is the mathematical difference between 12/15/99 and 12/31/99 or between 11/15/99 and 12/02/99? About two weeks. What is the mathematical difference between 12/15/99 and 01/03/00? About 99 years. And think about what that means to anything that uses dates or timing to calculate things that are to happen. Hypothetical Example #1. I use my Visa Card to charge $15.00 on December 15, 1999, and the bill is calculated on Monday, January 3, 2000. 99 years of 21% compounded interest on $15 can be over a billion dollars. Depending on where the minus sign is, either the company is going to think I haven't paid them for 99 years, and freeze my account, send me a bill for $1 billion in interest, or roll over into positive numbers, and tell me my account has $1 billion in available credit. "Hello, British Embassy? I'd like to buy Tristan Da Cunha and set up my own country. I can charge $500,000,000 to my American Express Card." Or it simply dumps every account with outstanding balances for manual handling as the numbers are outrageous, which effectively stops automatic billing. Or the system simply crashes. Scenario #2. A major petrochemical processing plant has a system that cooks a batch of chemicals for a certain period of time, before pushing that load out to the next process. The plant runs continuously, and batches are cooked according to time. A plant computer shoves a load in to cook for one hour beginning at 11:45 pm on December 31, 1999. At Midnight, one of these things happens: (1) the system notices that the batch has been in the oven too long, and pushes a batch of molten chemicals into the next process, where the process of spraying them causes an explosion. (2) the clock counter overflows and shuts down the whole system. (3) the system counter overflows and the batch isn't released, so it overcooks in the oven and perhaps explodes under high heat. (4) the batch stays in the oven while a new batch is shoved in, overloading the oven and causing an explosion. (5) any of these explosions carries back through the utilities and supplies, causing gas line explosions or power surges, as a plant that is eating perhaps 2 megawatts of power suddenly drops off the grid, causing an instant overflow and shutting down power for several areas. Scenario #3. Several power plants go into maintenance shutdown because they've been running continuously for 98 years and 7 months longer than the maximum 90 day operating maximum. Some Nuclear Power plant goes critical or shuts down because the system believes that the rods have been installed too long. So having looked at this issue, what can we do about it? I got thinking about this. In some systems, there's little or no room to expand their data files and the ability to remove running applications is impossible. Therefore any method that changes the system must allow their applications to continue running. And I thought of a method. By coding the date into a character field, effectively in base 32, it would be possible to encode a larger date and still only use 6 characters. By encoding the year to use the letters of the alphabet, e.g. AA through ZZ plus A0 through Z0, it is possible to cover more than 900 years, e.g. start counting with 1400 through 2300, thus covering any date that could have occurred during civilization. In fact, if one wants to encode the month and day - Month encoded to add A,B and C and day encoded as 1-9 and A-V, it is possible to use 4 digits for the year and still fit everything into 6 bytes. Or encode both and fit everything into 4 bytes. This would also then work for places using packed decimal for the six-digit year and thus only allowing 4 bytes. One of the things that is necessary is to make programs expecting numbers fail so that they can be changed, although it would be better to find the programs that use date fields and change them before they crash. Programs that read these records will have to expect both old and new format records, while programs that write them should only output the new format. The point is that with many sites having hundreds or even thousands of programs, the effort could be equivalent to three full-time people over a three year period at some sites. (Some companies have thousands or tens of thousands of programs in their libraries.) This is extra and additional maintenance on top of current maintenance. Expensive overhead that will get worse in the future as it needs to be more urgently done. What is needed are automated searching and checking facilities to find programs that manipulate dates and change those programs to handle a new date format using this compressed date format I have thought of. If we do not make the changes, we could be looking at failed programs, massive errors, disasters and setbacks that could produce serious, perhaps even fatal problems. It can't be done in a hurry in the last 6 months of 1999. Let us not forget the amount of time needed to do updates, which could be days or weeks, depending on how good the automated tools are and how many applications they have. What do we need to do? (1). If your site has inhouse applications, and lots of source files, you need to push for the acquisition of automated checking tools. (2). You need to push for the manpower and resources necessary to do the work now rather than later, because "later" won't be budgeted for. (3). You need to push for the updating of databases to allow full 8-digit dates. (4). Push for all reports to eliminate use of 6-digit dates, even in display fields. (5). Find out what your vendor is doing if you use canned applications. If we work on the problem now while there is time, we can do this with less error and better control, then trying to rush fixes in November of 1999 when errors could spell disaster. If you have better ideas on how to solve the six-digit problem, please write back. ---- To Reply to this message, write to <PROBLEMS(a)TDR.COM>; for private replies or subscriptions use <problems-request(a)tdr.com>; or use newsgroup <tdr.problems>. Please feel free to redistribute this article widely. This message is file ftp.digex.net:/pub/access/tdarcos/0026

1 0

EU Summer Time update
by Peter Ilieve June 8, 1994

June 8, 1994

The European Union bureaucracy has edged a step closer to a 7th Directive on summer-time arrangements. I have the text of a Common Position ((EC No 9/94) and a statement of the Council's reasons dated 4 March 94, reported in the Official Journal of the EC, No. C 137/38--41. Since I reported on the draft directive in March, 1998 has been removed from the scope of the 7th directive and the introduction of a common end date at the end of October has been brought forward to 1996 from 1997. No actual dates have changed. The dates again: Year Start End End (UK & Eire, 1995 only) (rule) (last Sun) (last Sun) (4th Sun) 1995 26 March 24 September 22 October 1996 31 March 27 October 1997 30 March 26 October In the statement of reasons it said the Council had rejected an amendment from the European Parliament relating to having a single timezone for the whole EU, noting that the Commission had said it was beyond the scope of the directive. It still looks unlikely to me that this idea, put forward in the UK from time to time, will ever come to pass. Normally each directive includes a provision that a new directive will be in place on 1 Jan of the last year covered by the preceeding one. This is always ignored, here we are in June and we still don't have the directive promised for January. This Common Position breaks new ground in that it tells the Commission to have proposals ready by 1 Jan 96, so a new directive can be adopted by 1 Jan 97. We will have to wait and see if this makes any difference. I think this is the final step before the directive is adopted but the Edinburgh EC Information Office could still give no guess as to when that might be. Peter Ilieve peter(a)memex.co.uk

1 0

Re: proposed corrections for Russia, Ukraine, Bahamas
by ado June 4, 1994

June 4, 1994

The file ~ftp/pub/tzdata94e.tar.gz on elsie.nci.nih.gov (128.231.16.1) incorporates the proposed changes. --ado

1 0

proposed corrections for Russia, Ukraine, Bahamas
by eggert＠twinsun.com June 3, 1994

June 3, 1994

The letter from "Andy J. Chichak" <chch(a)gateway.tiasur.tomsk.su> about Tomsk prompted me to check the Russian time zone data more carefully. Unfortunately it's a mess, as Shanks was published in 1991, a year that saw chaos in Russian time zones. Though it's hard to know what the correct rules are, it _is_ clear that the rules I submitted last year to the tz database are incorrect, since I got lost with the +1hour -1hour business and ended up omitting a timezone just west of the Urals. Given Chichak's comments about being N hours away from Moscow, I decided that the most likely possibility is that Russia kept in synch with Moscow (for which we already have a detailed post-1991 update from "Andrew A. Chernov" <ache(a)astral.msk.su>). I'd guess also that Belarus followed suit, but (as described below) we know that Ukraine did not, so I'd guess the other western bits of the ex-Soviet Union stuck with EET instead of Moscow time. We have no data on Central Asia and the Caucausus, so I'd guess we should stick with the pre-1991 rules for it until we have more data. The following proposed corrections insert that missing timezone (its biggest city is Kuybyshev) and bump the remaining Russian timezones by one; this gives the proper value for Tomsk and Novosibirsk as reported by Chichak. The latest _Economist_ reports that the Crimea, as part of its attempt to break away from Ukraine, has switched from Kiev time to Moscow time, so I've proposed another timezone entry Europe/Simferopol to take this into account. Also, more people seem to be calling Macedonia ``Macedonia'' instead of the odd ``The Former Yugoslav Republic of Macedonia'' moniker that was first pasted on it, so I think we should call it by its common name. Finally, there is a minor typo in the Bahamas entry. =================================================================== RCS file: RCS/northamerica,v retrieving revision 1994.4 retrieving revision 1994.4.1.1 diff -c -r1994.4 -r1994.4.1.1 *** northamerica 1994/02/07 14:57:50 1994.4 --- northamerica 1994/05/29 04:38:57 1994.4.1.1 *************** *** 629,635 **** # Bahamas # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S ! Rule Bahamas 1912 max - Mar 2 0:00 0 S Rule Bahamas 1964 max - Oct lastSun 2:00 0 S Rule Bahamas 1964 1986 - Apr lastSun 2:00 1:00 D Rule Bahamas 1987 max - Apr Sun>=1 2:00 1:00 D --- 629,635 ---- # Bahamas # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S ! Rule Bahamas 1912 only - Mar 2 0:00 0 S Rule Bahamas 1964 max - Oct lastSun 2:00 0 S Rule Bahamas 1964 1986 - Apr lastSun 2:00 1:00 D Rule Bahamas 1987 max - Apr Sun>=1 2:00 1:00 D =================================================================== RCS file: RCS/asia,v retrieving revision 1994.4 retrieving revision 1994.4.1.1 diff -c -r1994.4 -r1994.4.1.1 *** asia 1994/02/07 14:57:49 1994.4 --- asia 1994/05/29 04:38:57 1994.4.1.1 *************** *** 29,39 **** # 4:00 BSK BSD Baku* # 4:00 GST GDT Gulf* # 4:30 AFT Afghanistan* ! # 5:00 TSK TSD Tashkent* # 5:00 PKT Pakistan* # 5:30 IST IST India # 5:45 NPT Nepal* # 6:00 BGT Bengal, Bangladesh* # 6:30 BMT Burma* # 7:00 ICT Indochina* # 7:00 JVT Java* --- 29,40 ---- # 4:00 BSK BSD Baku* # 4:00 GST GDT Gulf* # 4:30 AFT Afghanistan* ! # 5:00 ASK ASD Ashkhabad* # 5:00 PKT Pakistan* # 5:30 IST IST India # 5:45 NPT Nepal* # 6:00 BGT Bengal, Bangladesh* + # 6:00 TSK TSD Tashkent* # 6:30 BMT Burma* # 7:00 ICT Indochina* # 7:00 JVT Java* *************** *** 60,72 **** ############################################################################### # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Russia 1981 1984 - Apr 1 0:00 1:00 D Rule Russia 1981 1983 - Oct 1 0:00 0 K ! Rule Russia 1984 1990 - Sep lastSun 3:00 0 K ! Rule Russia 1985 1990 - Mar lastSun 2:00 1:00 D ! Rule Russia 1992 max - Sep lastSun 2:00s 0 K ! Rule Russia 1992 max - Mar lastSun 2:00s 1:00 D # Afghanistan # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 61,74 ---- ############################################################################### + # From Paul Eggert <eggert(a)twinsun.com> (May 28, 1994): + # We don't know what happened to the clocks in the Caucausus and the ex-Soviet + # Central Asia after 1990. Until we get more info, stick with the pre-1991 rules. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Russia 1981 1984 - Apr 1 0:00 1:00 D Rule Russia 1981 1983 - Oct 1 0:00 0 K ! Rule Russia 1984 max - Sep lastSun 3:00 0 K ! Rule Russia 1985 max - Mar lastSun 2:00 1:00 D # Afghanistan # Zone NAME GMTOFF RULES FORMAT [UNTIL] *************** *** 78,92 **** # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Yerevan 2:58:00 - LMT 1924 May 2 3:00 - MSK 1957 Mar ! 4:00 Russia BS%s 1991 Sep 29 3:00 ! 3:00 Russia MS%s # Azerbaijan # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Baku 3:19:24 - LMT 1924 May 2 3:00 - MSK 1957 Mar ! 4:00 Russia BS%s 1991 Sep 29 3:00 ! 3:00 Russia MS%s # Bahrain # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 80,92 ---- # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Yerevan 2:58:00 - LMT 1924 May 2 3:00 - MSK 1957 Mar ! 4:00 Russia BS%s # Azerbaijan # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Baku 3:19:24 - LMT 1924 May 2 3:00 - MSK 1957 Mar ! 4:00 Russia BS%s # Bahrain # Zone NAME GMTOFF RULES FORMAT [UNTIL] *************** *** 277,284 **** Zone Asia/Tbilisi 2:59:16 - LMT 1880 2:59 - LST 1924 May 2 3:00 - MSK 1957 Mar ! 4:00 Russia BS%s 1991 Sep 29 3:00 ! 3:00 Russia MS%s # India # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 277,283 ---- Zone Asia/Tbilisi 2:59:16 - LMT 1880 2:59 - LST 1924 May 2 3:00 - MSK 1957 Mar ! 4:00 Russia BS%s # India # Zone NAME GMTOFF RULES FORMAT [UNTIL] *************** *** 516,523 **** # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Almaty 5:07:48 - LMT 1924 May 2 5:00 - TSK 1957 Mar ! 6:00 Russia TS%s 1991 Sep 29 3:00 ! 5:00 Russia TS%s ############################################################################### --- 515,521 ---- # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Almaty 5:07:48 - LMT 1924 May 2 5:00 - TSK 1957 Mar ! 6:00 Russia TS%s ############################################################################### *************** *** 565,572 **** # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Frunze 4:58:24 - LMT 1924 May 2 5:00 - TSK 1957 Mar ! 6:00 Russia TS%s 1991 Sep 29 3:00 ! 5:00 Russia TS%s # Laos # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 563,569 ---- # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Frunze 4:58:24 - LMT 1924 May 2 5:00 - TSK 1957 Mar ! 6:00 Russia TS%s # Laos # Zone NAME GMTOFF RULES FORMAT [UNTIL] *************** *** 755,762 **** # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Dushanbe 4:35:12 - LMT 1924 May 2 5:00 - TSK 1957 Mar ! 6:00 Russia TS%s 1991 Sep 29 3:00 ! 5:00 Russia TS%s # Thailand # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 752,758 ---- # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Dushanbe 4:35:12 - LMT 1924 May 2 5:00 - TSK 1957 Mar ! 6:00 Russia TS%s # Thailand # Zone NAME GMTOFF RULES FORMAT [UNTIL] *************** *** 767,775 **** # Turkmenistan # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Ashkhabad 3:53:32 - LMT 1924 May 2 ! 4:00 - BSK 1957 Mar ! 5:00 Russia SS%s 1991 Sep 29 3:00 ! 4:00 Russia BS%s # United Arab Emirates # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 763,770 ---- # Turkmenistan # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Ashkhabad 3:53:32 - LMT 1924 May 2 ! 4:00 - ASK 1957 Mar ! 5:00 Russia AS%s # United Arab Emirates # Zone NAME GMTOFF RULES FORMAT [UNTIL] *************** *** 780,787 **** # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Tashkent 4:37:12 - LMT 1924 May 2 5:00 - TSK 1957 Mar ! 6:00 Russia TS%s 1991 Sep 29 3:00 ! 5:00 Russia TS%s # Vietnam # From Paul Eggert <eggert(a)twinsun.com> (November 18, 1993): --- 775,781 ---- # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Tashkent 4:37:12 - LMT 1924 May 2 5:00 - TSK 1957 Mar ! 6:00 Russia TS%s # Vietnam # From Paul Eggert <eggert(a)twinsun.com> (November 18, 1993): =================================================================== RCS file: RCS/europe,v retrieving revision 1994.4 retrieving revision 1994.4.1.1 diff -c -r1994.4 -r1994.4.1.1 *** europe 1994/02/07 14:57:50 1994.4 --- europe 1994/05/29 04:38:57 1994.4.1.1 *************** *** 32,46 **** # 2:00 EET+DST Eastern Europe # 3:00 MSK MSD Moscow # 3:00 TUR+DST Turkey (no longer used)* ! # 4:00 ESK ESD Yekaterinburg* ! # 5:00 OSK OSD Omsk* ! # 6:00 NSK NSD Novosibirsk ! # 7:00 ISK ISD Irkutsk* ! # 8:00 YSK YSD Yakutsk* ! # 9:00 VSK VSD Vladivostok* ! # 10:00 GSK GSD Magadan* ! # 11:00 PSK PSD Petropavlovsk-Kamchatski* ! # 12:00 ASK ASD Anadyr* # # See the `africa' file for Zone naming conventions. # --- 32,47 ---- # 2:00 EET+DST Eastern Europe # 3:00 MSK MSD Moscow # 3:00 TUR+DST Turkey (no longer used)* ! # 4:00 KSK KSD Kuybyshev* ! # 5:00 ESK ESD Yekaterinburg* ! # 6:00 OSK OSD Omsk* ! # 7:00 NSK NSD Novosibirsk ! # 8:00 ISK ISD Irkutsk* ! # 9:00 YSK YSD Yakutsk* ! # 10:00 VSK VSD Vladivostok* ! # 11:00 GSK GSD Magadan* ! # 12:00 PSK PSD Petropavlovsk-Kamchatski* ! # 13:00 ASK ASD Anadyr* # # See the `africa' file for Zone naming conventions. # *************** *** 421,427 **** # ## <years> is either a single year or a hyphen separated range, with -- # ## also accepted as I use this in TeX a lot. # ## <start date> and <end date> are a digit followed bu a month name. ! # ## It is either an nth Saturday or an explcit date, depending on <flags>. # ## 0 and/or none are used when there is no date, as during 1968--71. # ## <flags> can contain `fixed' to indicate explicit dates and `double' # ## to indicate double summer time dates are present. --- 422,428 ---- # ## <years> is either a single year or a hyphen separated range, with -- # ## also accepted as I use this in TeX a lot. # ## <start date> and <end date> are a digit followed bu a month name. ! # ## It is either an nth Saturday or an explicit date, depending on <flags>. # ## 0 and/or none are used when there is no date, as during 1968--71. # ## <flags> can contain `fixed' to indicate explicit dates and `double' # ## to indicate double summer time dates are present. *************** *** 730,739 **** Rule Russia 1921 only - Oct 1 0:00 0 K Rule Russia 1981 1984 - Apr 1 0:00 1:00 D Rule Russia 1981 1983 - Oct 1 0:00 0 K ! Rule Russia 1984 1990 - Sep lastSun 2:00s 0 K ! Rule Russia 1985 1990 - Mar lastSun 2:00s 1:00 D ! Rule Russia 1992 max - Sep lastSun 2:00s 0 K ! Rule Russia 1992 max - Mar lastSun 2:00s 1:00 D # These are for backward compatibility with older versions. --- 731,738 ---- Rule Russia 1921 only - Oct 1 0:00 0 K Rule Russia 1981 1984 - Apr 1 0:00 1:00 D Rule Russia 1981 1983 - Oct 1 0:00 0 K ! Rule Russia 1984 max - Sep lastSun 2:00s 0 K ! Rule Russia 1985 max - Mar lastSun 2:00s 1:00 D # These are for backward compatibility with older versions. *************** *** 813,820 **** 2:31 Russia LST%s 1919 Jul 1 2:00 3:00 Russia MS%s 1922 Oct 2:00 - EET 1930 Jun 21 ! 3:00 Russia MS%s 1991 Sep 29 3:00 ! 2:00 Russia MS%s # Belgium # Whitman and Shanks disagree; go with Shanks, usually. --- 812,822 ---- 2:31 Russia LST%s 1919 Jul 1 2:00 3:00 Russia MS%s 1922 Oct 2:00 - EET 1930 Jun 21 ! 3:00 Russia MS%s 1991 Mar 31 2:00s ! # From Paul Eggert <eggert(a)twinsun.com> (May 28, 1994): A guess at recent dates: ! 2:00 1:00 "EET DST" 1991 Sep 29 2:00s ! 2:00 - EET 1992 Jan 19 2:00s ! 3:00 Russia MS%s # Belgium # Whitman and Shanks disagree; go with Shanks, usually. *************** *** 966,973 **** 2:00 - EET 1940 Aug 6 3:00 - MSK 1941 Sep 15 1:00 M-Eur MET%s 1944 Sep 22 ! 3:00 Russia MS%s 1989 Mar 26 2:00 ! 2:00 M-Eur MET%s # Finland # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S --- 968,976 ---- 2:00 - EET 1940 Aug 6 3:00 - MSK 1941 Sep 15 1:00 M-Eur MET%s 1944 Sep 22 ! 3:00 Russia MS%s 1989 Mar 26 2:00s ! 2:00 1:00 "EET DST" 1989 Sep 24 2:00s ! 2:00 M-Eur EET%s # Finland # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S *************** *** 1162,1168 **** # to the julian/gregorian calendar) over the period in question. # the winter begins on the Saturday next before St. Luke's day # (old style), or on St. Luke's day, if a Saturday. ! # St. Luke's day ought to be traceable from ecclesiatical sources. "old style" # might be a reference to the Julian calendar as opposed to Gregorian, or it # might mean something else (???). The Gregorian calendar was not introduced # in Iceland until 1700. --- 1165,1171 ---- # to the julian/gregorian calendar) over the period in question. # the winter begins on the Saturday next before St. Luke's day # (old style), or on St. Luke's day, if a Saturday. ! # St. Luke's day ought to be traceable from ecclesiastical sources. "old style" # might be a reference to the Julian calendar as opposed to Gregorian, or it # might mean something else (???). The Gregorian calendar was not introduced # in Iceland until 1700. *************** *** 1260,1267 **** 2:00 - EET 1940 Aug 5 3:00 - MSK 1941 Jul 1:00 M-Eur MET%s 1944 Aug 8 ! 3:00 Russia MS%s 1991 Sep 29 3:00 ! 2:00 M-Eur MET%s # Liechtenstein # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 1263,1271 ---- 2:00 - EET 1940 Aug 5 3:00 - MSK 1941 Jul 1:00 M-Eur MET%s 1944 Aug 8 ! 3:00 Russia MS%s 1991 Mar 31 2:00s ! 2:00 1:00 "EET DST" 1991 Sep 29 2:00s ! 2:00 M-Eur EET%s # Liechtenstein # Zone NAME GMTOFF RULES FORMAT [UNTIL] *************** *** 1280,1287 **** 1:00 - MET 1940 Aug 3 3:00 - MSK 1941 Jun 24 1:00 M-Eur MET%s 1944 Aug ! 3:00 Russia MS%s 1991 Sep 29 3:00 ! 2:00 M-Eur MET%s # Luxembourg # Whitman disagrees with most of these dates in minor ways; go with Shanks. --- 1284,1292 ---- 1:00 - MET 1940 Aug 3 3:00 - MSK 1941 Jun 24 1:00 M-Eur MET%s 1944 Aug ! 3:00 Russia MS%s 1991 Mar 31 2:00s ! 2:00 1:00 "EET DST" 1991 Sep 29 2:00s ! 2:00 M-Eur EET%s # Luxembourg # Whitman disagrees with most of these dates in minor ways; go with Shanks. *************** *** 1319,1325 **** 1:00 Belgium MET%s 1979 Apr 1 2:00 1:00 M-Eur MET%s ! # The Former Yugoslav Republic of Macedonia # They switched from the Julian to the Gregorian calendar on 1918 Mar 18. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Skopje 1:25:44 - LMT 1884 --- 1324,1330 ---- 1:00 Belgium MET%s 1979 Apr 1 2:00 1:00 M-Eur MET%s ! # Macedonia # They switched from the Julian to the Gregorian calendar on 1918 Mar 18. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Skopje 1:25:44 - LMT 1884 *************** *** 1351,1358 **** # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Chisinau 1:55:20 - LMT 1924 May 2 2:00 - EET 1930 Jun 21 ! 3:00 - MSK 1981 Apr ! 3:00 Russia MS%s 1991 Sep 29 2:00s 2:00 M-Eur EET%s # Monaco --- 1356,1363 ---- # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Chisinau 1:55:20 - LMT 1924 May 2 2:00 - EET 1930 Jun 21 ! 3:00 Russia MS%s 1991 Mar 31 2:00s ! 2:00 1:00 "EET DST" 1991 Sep 29 2:00s 2:00 M-Eur EET%s # Monaco *************** *** 1435,1441 **** Rule Poland 1919 only - Apr 15 2:00s 1:00 " DST" # Whitman gives 1944 Nov 30; go with Shanks. Rule Poland 1944 only - Oct 4 2:00 0 - ! # For 1944-1948 Whitman gives the previous day; go with SHanks. Rule Poland 1945 only - Apr 29 0:00 1:00 " DST" Rule Poland 1945 only - Nov 1 0:00 0 - Rule Poland 1946 only - Apr 14 0:00 1:00 " DST" --- 1440,1446 ---- Rule Poland 1919 only - Apr 15 2:00s 1:00 " DST" # Whitman gives 1944 Nov 30; go with Shanks. Rule Poland 1944 only - Oct 4 2:00 0 - ! # For 1944-1948 Whitman gives the previous day; go with Shanks. Rule Poland 1945 only - Apr 29 0:00 1:00 " DST" Rule Poland 1945 only - Nov 1 0:00 0 - Rule Poland 1946 only - Apr 14 0:00 1:00 " DST" *************** *** 1574,1647 **** 2:00 M-Eur EET%s # Russia ! # From Paul Eggert <eggert(a)twinsun.com> (November 18, 1993): # Moscow and Novosibirsk time zone names, and Moscow rules after 1991, # are from Andrew A. Chernov <ache(a)astral.msk.su>. ! # I invented the other time zone names. ! # The rest is from Shanks; it's probably wrong after 1991. ! # We're not sure whether St Petersburg switched in step with Moscow after 1991; ! # it might be a useless name, so we'll comment it out for now. # # From Shanks (1991): # Western Russia switched from the Julian to the Gregorian calendar ! # on 1918 Jan 14. Eatern Russia switched on 1920 Mar 18. # In 1929 the Soviet Union instituted a 5 day week; in 1932 it instituted # a 6 day week; on 1940 Jun 27 it returned to the Gregorian week. # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! #Zone Europe/St_Petersburg 2:30:20 - LMT 1880 ! # 2:01 Russia LST%s 1919 Jul 1 2:00 ! # 3:00 Russia MS%s 1922 Oct ! # 2:00 - EET 1930 Jun 21 ! # 3:00 Russia MS%s 1991 Sep 29 3:00 ! # 2:00 Russia SPS%s ! Zone Europe/Moscow 2:30:20 - LMT 1880 ! 2:31 Russia LST%s 1919 Jul 1 2:00 ! 3:00 Russia MS%s 1922 Oct ! 2:00 - EET 1930 Jun 21 ! 3:00 Russia MS%s 1991 Mar lastSun 2:00s ! 2:00 1:00 "EET DST" 1991 Sep lastSun 2:00s ! 2:00 - EET 1992 Jan 19 2:00s ! 3:00 Russia MS%s ! Zone Asia/Yekaterinburg 4:02:34 - LMT 1924 May 2 ! 4:00 - ESK 1957 Mar ! 5:00 Russia ES%s 1991 Sep 29 3:00 ! 4:00 Russia ES%s ! Zone Asia/Omsk 4:53:36 - LMT 1924 May 2 ! 5:00 - TSK 1957 Mar ! 6:00 Russia TS%s 1991 Sep 29 3:00 ! 5:00 Russia OS%s ! Zone Asia/Novosibirsk 5:31:40 - LMT 1924 May 2 ! 6:00 - NSK 1957 Mar ! 7:00 Russia NS%s 1991 Sep 29 3:00 ! 6:00 Russia NS%s ! Zone Asia/Irkutsk 6:57:20 - LMT 1880 ! 6:57 - LST 1924 May 2 ! 7:00 - ISK 1957 Mar ! 8:00 Russia IS%s 1991 Sep 29 3:00 ! 7:00 Russia IS%s ! Zone Asia/Yakutsk 8:38:40 - LMT 1924 May 2 ! 8:00 - YSK 1957 Mar ! 9:00 Russia YS%s 1991 Sep 29 3:00 ! 8:00 Russia YS%s ! Zone Asia/Vladivostok 8:47:44 - LMT 1880 ! 8:48 - LST 1924 May 2 ! 9:00 - VSK 1957 Mar ! 10:00 Russia VS%s 1991 Sep 29 3:00 ! 9:00 Russia VS%s # MSK is taken; settle for GSK. Zone Asia/Magadan 10:03:12 - LMT 1924 May 2 10:00 - GSK 1957 Mar ! 11:00 Russia GS%s 1991 Sep 29 3:00 ! 10:00 Russia GS%s # This name should be Asia/Petropavlovsk-Kamchatski, but that's too long. Zone Asia/Kamchatka 10:34:36 - LMT 1924 May 2 11:00 - PSK 1957 Mar ! 12:00 Russia PS%s 1991 Sep 29 3:00 ! 11:00 Russia PS%s Zone Asia/Anadyr 11:49:56 - LMT 1924 May 2 12:00 - ASK 1957 Mar ! 13:00 Russia AS%s 1991 Sep 29 3:00 ! 12:00 Russia AS%s # Serbia # They switched from the Julian to the Gregorian calendar on 1918 Mar 18. --- 1579,1669 ---- 2:00 M-Eur EET%s # Russia ! # From Paul Eggert <eggert(a)twinsun.com> (May 28, 1994): # Moscow and Novosibirsk time zone names, and Moscow rules after 1991, # are from Andrew A. Chernov <ache(a)astral.msk.su>. ! # I invented the other time zone names, and (unless otherwise specified) ! # guessed what happened after 1991; the clocks were chaotic, and we know little. ! # The rest is from Shanks. # # From Shanks (1991): # Western Russia switched from the Julian to the Gregorian calendar ! # on 1918 Jan 14. Eastern Russia switched on 1920 Mar 18. # In 1929 the Soviet Union instituted a 5 day week; in 1932 it instituted # a 6 day week; on 1940 Jun 27 it returned to the Gregorian week. # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Europe/Moscow 2:30:20 - LMT 1880 ! 2:31 Russia LST%s 1919 Jul 1 2:00 ! 3:00 Russia MS%s 1922 Oct ! 2:00 - EET 1930 Jun 21 ! 3:00 Russia MS%s 1991 Mar 31 2:00s ! 2:00 1:00 "EET DST" 1991 Sep 29 2:00s ! 2:00 - EET 1992 Jan 19 2:00s ! 3:00 Russia MS%s ! Zone Europe/Kuybyshev 3:20:36 - LMT 1924 May 2 ! 3:00 - KSK 1957 Mar ! 4:00 Russia KS%s 1991 Mar 31 2:00s ! 3:00 1:00 KSD 1991 Sep 29 2:00s ! 3:00 - KSK 1992 Jan 19 2:00s ! 4:00 Russia KS%s ! Zone Asia/Yekaterinburg 4:02:34 - LMT 1924 May 2 ! 4:00 - SSK 1957 Mar ! 5:00 Russia SS%s 1991 Mar 31 2:00s ! 4:00 1:00 SSD 1991 Sep 29 2:00s ! 4:00 - SSK 1992 Jan 19 2:00s ! 5:00 Russia ES%s # name change from Sverdlovsk ! Zone Asia/Omsk 4:53:36 - LMT 1924 May 2 ! 5:00 - OSK 1957 Mar ! 6:00 Russia OS%s 1991 Mar 31 2:00s ! 5:00 1:00 OSD 1991 Sep 29 2:00s ! 5:00 - OSK 1992 Jan 19 2:00s ! 6:00 Russia OS%s ! Zone Asia/Novosibirsk 5:31:40 - LMT 1924 May 2 ! 6:00 - NSK 1957 Mar ! 7:00 Russia NS%s 1991 Mar 31 2:00s ! 6:00 1:00 NSD 1991 Sep 29 2:00s ! 6:00 - NSK 1992 Jan 19 2:00s ! 7:00 Russia NS%s ! Zone Asia/Irkutsk 6:57:20 - LMT 1880 ! 6:57 - LST 1924 May 2 ! 7:00 - ISK 1957 Mar ! 8:00 Russia IS%s 1991 Mar 31 2:00s ! 7:00 1:00 ISD 1991 Sep 29 2:00s ! 7:00 - ISK 1992 Jan 19 2:00s ! 8:00 Russia IS%s ! Zone Asia/Yakutsk 8:38:40 - LMT 1924 May 2 ! 8:00 - YSK 1957 Mar ! 9:00 Russia YS%s 1991 Mar 31 2:00s ! 8:00 1:00 YSD 1991 Sep 29 2:00s ! 8:00 - YSK 1992 Jan 19 2:00s ! 9:00 Russia YS%s ! Zone Asia/Vladivostok 8:47:44 - LMT 1880 ! 8:48 - LST 1924 May 2 ! 9:00 - VSK 1957 Mar ! 10:00 Russia VS%s 1991 Mar 31 2:00s ! 9:00 1:00 VSD 1991 Sep 29 2:00s ! 9:00 - VSK 1992 Jan 19 2:00s ! 10:00 Russia VS%s # MSK is taken; settle for GSK. Zone Asia/Magadan 10:03:12 - LMT 1924 May 2 10:00 - GSK 1957 Mar ! 11:00 Russia GS%s 1991 Mar 31 2:00s ! 10:00 1:00 GSD 1991 Sep 29 2:00s ! 10:00 - GSK 1992 Jan 19 2:00s ! 11:00 Russia GS%s # This name should be Asia/Petropavlovsk-Kamchatski, but that's too long. Zone Asia/Kamchatka 10:34:36 - LMT 1924 May 2 11:00 - PSK 1957 Mar ! 12:00 Russia PS%s 1991 Mar 31 2:00s ! 11:00 1:00 PSD 1991 Sep 29 2:00s ! 11:00 - PSK 1992 Jan 19 2:00s ! 12:00 Russia PS%s Zone Asia/Anadyr 11:49:56 - LMT 1924 May 2 12:00 - ASK 1957 Mar ! 13:00 Russia AS%s 1991 Mar 31 2:00s ! 12:00 1:00 ASD 1991 Sep 29 2:00s ! 12:00 - ASK 1992 Jan 19 2:00s ! 13:00 Russia AS%s # Serbia # They switched from the Julian to the Gregorian calendar on 1918 Mar 18. *************** *** 1816,1827 **** Rule Ukraine 1921 only - Sep 1 0:00 1:00 " DST" Rule Ukraine 1921 only - Oct 1 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Europe/Kiev 2:02:04 - LMT 1880 2:02 Russia LST%s 1919 Jul 1 2:00 2:02 Ukraine LST%s 1924 May 2 2:00 - EET 1930 Jun 21 3:00 Russia MS%s 1990 Jul 17 2:00 M-Eur EET%s ############################################################################### --- 1838,1861 ---- Rule Ukraine 1921 only - Sep 1 0:00 1:00 " DST" Rule Ukraine 1921 only - Oct 1 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Europe/Kiev 2:02:04 - LMT 1880 2:02 Russia LST%s 1919 Jul 1 2:00 2:02 Ukraine LST%s 1924 May 2 2:00 - EET 1930 Jun 21 3:00 Russia MS%s 1990 Jul 17 2:00 M-Eur EET%s + Zone Europe/Simferopol 2:16:24 - LMT 1880 + 2:08 Russia LST%s 1919 Jul 1 2:00 + 2:08 Ukraine LST%s 1924 May 2 + 2:00 - EET 1930 Jun 21 + 3:00 Russia MS%s 1991 Mar 31 2:00s + 2:00 1:00 "EET DST" 1991 Sep 29 2:00s + # From Paul Eggert <eggert(a)twinsun.com> (May 28, 1994): + # Today's _Economist_ (p 45) reports that Crimea switched + # from Kiev to Moscow time sometime after the January elections. + # For now, we'll guess that there was a 2-hour leap forward on March 27. + 2:00 M-Eur EET%s 1994 Mar 27 2:00s + 3:00 Russia MS%s ###############################################################################

1 0

v28i034: strftime - strftime(3) and date(1) implementation, V6.1, Part01/01
by Monty Solomon May 12, 1994

May 12, 1994

FYI Begin forwarded message: Path: decwrl!vixie!vixie!not-for-mail From: arnold(a)skeeve.atl.ga.us (Arnold Robbins) Newsgroups: comp.sources.unix Subject: v28i034: strftime - strftime(3) and date(1) implementation, V6.1, Part01/01 Date: 11 May 1994 22:11:06 -0700 Organization: Vixie Enterprises Lines: 1303 Sender: vixie(a)vix.com Approved: vixie(a)gw.home.vix.com Nntp-Posting-Host: gw.home.vix.com To: unix-sources(a)pa.dec.com Submitted-By: arnold(a)skeeve.atl.ga.us (Arnold Robbins) Posting-Number: Volume 28, Issue 34 Archive-Name: strftime-6.1/part01 In Volume 27, Issue 207 our moderator writes: >[ this recurring package is the cleanest, nicest date(1) and strftime(3) > i have ever seen, including all free or vendor systems. --vix ] To which I can only say, "gosh, thanks!". I had written: > It seems to be an annual event, something in the circling of the stars > overhead, that requires me to post this, at least once a year. (:-) > > I sincerely hope this will be it (at least 'til next year! :-) Alas, it seems to be an annual event that shortly after posting my package, I also post bug fixes. :-) There are three main fixes here. 1) An update to the date.1 man page to reflect that POSIX.2 is not in draft any more, 2) Yet another fix to the %V code, and 3) Portability enhancements if there is no tm_zone field in the struct tm. Thanks to all who sent mail and helped me track down the ISO 8601 issues. This is strftime 6.1. The package is small enough I'm just reposting the whole thing. Arnold Robbins -- The Basement Computer | Laundry increases Internet: arnold(a)skeeve.ATL.GA.US | exponentially in the UUCP: emory!skeeve!arnold | number of children. Bitnet: Forget it. Get on a real network. | -- Miriam Robbins ------------------------- cut here ------------------------------------ #! /bin/sh echo - 'README' cat << 'EOF' > 'README' Tue May 10 21:43:29 EDT 1994 This package implements the Posix 1003.2 date command, as a wrapper around an extended version of the ANSI strftime(3) library routine. Everything in it is public domain. Arnold Robbins -- The Basement Computer | Laundry increases Internet: arnold(a)skeeve.ATL.GA.US | exponentially in the UUCP: { gatech, emory }!skeeve!arnold | number of children. Bitnet: Forget it. Get on a real network. | -- Miriam Robbins EOF echo - 'Makefile' cat << 'EOF' > 'Makefile' # Makefile for PD date and strftime SRCS= date.c strftime.c OBJS= date.o strftime.o DOCS= date.1 strftime.3 # Uncomment the define of HAVE_TZNAME if your system has the tzname[] array. # Uncomment the define of TM_IN_SYS_TIME if struct tm is in <sys/time.h>. # Uncomment the define of TM_ZONE if your struct tm has the tm_zone field. CFLAGS= -O #-DHAVE_TZNAME #-DTM_IN_SYS_TIME #-DHAVE_TM_ZONE date: $(OBJS) $(CC) $(CFLAGS) $(OBJS) -o $@ date.o: date.c strftime.o: strftime.c EOF echo - 'date.c' cat << 'EOF' > 'date.c' /* * date.c * * Public domain implementation of Posix 1003.2 * date command. Lets strftime() do the dirty work. * * Arnold Robbins * arnold(a)skeeve.atl.ga.us * April, 1991 * * Bug fix courtesy of Chris Ritson (C.R.Ritson(a)newcastle.ac.uk) * February, 1994. */ #include <stdio.h> #include <sys/types.h> #include <time.h> extern char *malloc(); extern size_t strftime(); extern int getopt(); extern int optind; int main(argc, argv) int argc; char **argv; { time_t clock; struct tm *now; int c, size, ret; char *defhow = "%a %b %e %H:%M:%S %Z %Y"; char *howto = defhow; char *buf; while ((c = getopt(argc, argv, "u")) != -1) switch (c) { case 'u': putenv("TZ=GMT0"); break; default: fprintf(stderr, "usage: %s [-u] [+format_str]\n", argv[0]); exit(1); } time(& clock); now = localtime(& clock); if (optind < argc && argv[optind][0] == '+') howto = & argv[optind][1]; size = strlen(howto) * 10; if (size < 26) size = 26; if ((buf = malloc(size)) == NULL) { perror("not enough memory"); exit(1); } ret = strftime(buf, size, howto, now); if (ret != 0) printf("%s\n", buf); else { fprintf(stderr, "conversion failed\n"); exit(1); } exit(0); } EOF echo - 'strftime.c' cat << 'EOF' > 'strftime.c' /* * strftime.c * * Public-domain implementation of ANSI C library routine. * * It's written in old-style C for maximal portability. * However, since I'm used to prototypes, I've included them too. * * If you want stuff in the System V ascftime routine, add the SYSV_EXT define. * For extensions from SunOS, add SUNOS_EXT. * For stuff needed to implement the P1003.2 date command, add POSIX2_DATE. * For VMS dates, add VMS_EXT. * For complete POSIX semantics, add POSIX_SEMANTICS. * * The code for %c, %x, and %X is my best guess as to what's "appropriate". * This version ignores LOCALE information. * It also doesn't worry about multi-byte characters. * So there. * * This file is also shipped with GAWK (GNU Awk), gawk specific bits of * code are included if GAWK is defined. * * Arnold Robbins * January, February, March, 1991 * Updated March, April 1992 * Updated April, 1993 * Updated February, 1994 * Updated May, 1994 * * Fixes from ado(a)elsie.nci.nih.gov * February 1991, May 1992 * Fixes from Tor Lillqvist tml(a)tik.vtt.fi * May, 1993 * Further fixes from ado(a)elsie.nci.nih.gov * February 1994 */ #ifndef GAWK #include <stdio.h> #include <ctype.h> #include <string.h> #include <time.h> #endif #if defined(TM_IN_SYS_TIME) || ! defined(GAWK) #include <sys/types.h> #include <sys/time.h> #endif /* defaults: season to taste */ #define SYSV_EXT 1 /* stuff in System V ascftime routine */ #define SUNOS_EXT 1 /* stuff in SunOS strftime routine */ #define POSIX2_DATE 1 /* stuff in Posix 1003.2 date command */ #define VMS_EXT 1 /* include %v for VMS date format */ #ifndef GAWK #define POSIX_SEMANTICS 1 /* call tzset() if TZ changes */ #endif #if defined(POSIX2_DATE) #if ! defined(SYSV_EXT) #define SYSV_EXT 1 #endif #if ! defined(SUNOS_EXT) #define SUNOS_EXT 1 #endif #endif #if defined(POSIX2_DATE) #define adddecl(stuff) stuff #else #define adddecl(stuff) #endif #undef strchr /* avoid AIX weirdness */ #ifndef __STDC__ #define const /**/ extern void *malloc(); extern void *realloc(); extern void tzset(); extern char *strchr(); extern char *getenv(); static int weeknumber(); adddecl(static int iso8601wknum();) #else extern void *malloc(unsigned count); extern void *realloc(void *ptr, unsigned count); extern void tzset(void); extern char *strchr(const char *str, int ch); extern char *getenv(const char *v); static int weeknumber(const struct tm *timeptr, int firstweekday); adddecl(static int iso8601wknum(const struct tm *timeptr);) #endif #ifdef __GNUC__ #define inline __inline__ #else #define inline /**/ #endif #define range(low, item, hi) max(low, min(item, hi)) #if !defined(OS2) && !defined(MSDOS) && defined(HAVE_TZNAME) extern char *tzname[2]; extern int daylight; #endif /* min --- return minimum of two numbers */ #ifndef __STDC__ static inline int min(a, b) int a, b; #else static inline int min(int a, int b) #endif { return (a < b ? a : b); } /* max --- return maximum of two numbers */ #ifndef __STDC__ static inline int max(a, b) int a, b; #else static inline int max(int a, int b) #endif { return (a > b ? a : b); } /* strftime --- produce formatted time */ #ifndef __STDC__ size_t strftime(s, maxsize, format, timeptr) char *s; size_t maxsize; const char *format; const struct tm *timeptr; #else size_t strftime(char *s, size_t maxsize, const char *format, const struct tm *timeptr) #endif { char *endp = s + maxsize; char *start = s; auto char tbuf[100]; int i; static short first = 1; #ifdef POSIX_SEMANTICS static char *savetz = NULL; static int savetzlen = 0; char *tz; #endif /* POSIX_SEMANTICS */ #ifndef HAVE_TM_ZONE extern char *timezone(); struct timeval tv; struct timezone zone; #endif /* HAVE_TM_ZONE */ /* various tables, useful in North America */ static const char *days_a[] = { "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", }; static const char *days_l[] = { "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", }; static const char *months_a[] = { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec", }; static const char *months_l[] = { "January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December", }; static const char *ampm[] = { "AM", "PM", }; if (s == NULL || format == NULL || timeptr == NULL || maxsize == 0) return 0; /* quick check if we even need to bother */ if (strchr(format, '%') == NULL && strlen(format) + 1 >= maxsize) return 0; #ifndef POSIX_SEMANTICS if (first) { tzset(); first = 0; } #else /* POSIX_SEMANTICS */ tz = getenv("TZ"); if (first) { if (tz != NULL) { int tzlen = strlen(tz); savetz = (char *) malloc(tzlen + 1); if (savetz != NULL) { savetzlen = tzlen + 1; strcpy(savetz, tz); } } tzset(); first = 0; } /* if we have a saved TZ, and it is different, recapture and reset */ if (tz && savetz && (tz[0] != savetz[0] || strcmp(tz, savetz) != 0)) { i = strlen(tz) + 1; if (i > savetzlen) { savetz = (char *) realloc(savetz, i); if (savetz) { savetzlen = i; strcpy(savetz, tz); } } else strcpy(savetz, tz); tzset(); } #endif /* POSIX_SEMANTICS */ for (; *format && s < endp - 1; format++) { tbuf[0] = '\0'; if (*format != '%') { *s++ = *format; continue; } again: switch (*++format) { case '\0': *s++ = '%'; goto out; case '%': *s++ = '%'; continue; case 'a': /* abbreviated weekday name */ if (timeptr->tm_wday < 0 || timeptr->tm_wday > 6) strcpy(tbuf, "?"); else strcpy(tbuf, days_a[timeptr->tm_wday]); break; case 'A': /* full weekday name */ if (timeptr->tm_wday < 0 || timeptr->tm_wday > 6) strcpy(tbuf, "?"); else strcpy(tbuf, days_l[timeptr->tm_wday]); break; #ifdef SYSV_EXT case 'h': /* abbreviated month name */ #endif case 'b': /* abbreviated month name */ if (timeptr->tm_mon < 0 || timeptr->tm_mon > 11) strcpy(tbuf, "?"); else strcpy(tbuf, months_a[timeptr->tm_mon]); break; case 'B': /* full month name */ if (timeptr->tm_mon < 0 || timeptr->tm_mon > 11) strcpy(tbuf, "?"); else strcpy(tbuf, months_l[timeptr->tm_mon]); break; case 'c': /* appropriate date and time representation */ sprintf(tbuf, "%s %s %2d %02d:%02d:%02d %d", days_a[range(0, timeptr->tm_wday, 6)], months_a[range(0, timeptr->tm_mon, 11)], range(1, timeptr->tm_mday, 31), range(0, timeptr->tm_hour, 23), range(0, timeptr->tm_min, 59), range(0, timeptr->tm_sec, 61), timeptr->tm_year + 1900); break; case 'd': /* day of the month, 01 - 31 */ i = range(1, timeptr->tm_mday, 31); sprintf(tbuf, "%02d", i); break; case 'H': /* hour, 24-hour clock, 00 - 23 */ i = range(0, timeptr->tm_hour, 23); sprintf(tbuf, "%02d", i); break; case 'I': /* hour, 12-hour clock, 01 - 12 */ i = range(0, timeptr->tm_hour, 23); if (i == 0) i = 12; else if (i > 12) i -= 12; sprintf(tbuf, "%02d", i); break; case 'j': /* day of the year, 001 - 366 */ sprintf(tbuf, "%03d", timeptr->tm_yday + 1); break; case 'm': /* month, 01 - 12 */ i = range(0, timeptr->tm_mon, 11); sprintf(tbuf, "%02d", i + 1); break; case 'M': /* minute, 00 - 59 */ i = range(0, timeptr->tm_min, 59); sprintf(tbuf, "%02d", i); break; case 'p': /* am or pm based on 12-hour clock */ i = range(0, timeptr->tm_hour, 23); if (i < 12) strcpy(tbuf, ampm[0]); else strcpy(tbuf, ampm[1]); break; case 'S': /* second, 00 - 61 */ i = range(0, timeptr->tm_sec, 61); sprintf(tbuf, "%02d", i); break; case 'U': /* week of year, Sunday is first day of week */ sprintf(tbuf, "%02d", weeknumber(timeptr, 0)); break; case 'w': /* weekday, Sunday == 0, 0 - 6 */ i = range(0, timeptr->tm_wday, 6); sprintf(tbuf, "%d", i); break; case 'W': /* week of year, Monday is first day of week */ sprintf(tbuf, "%02d", weeknumber(timeptr, 1)); break; case 'x': /* appropriate date representation */ sprintf(tbuf, "%s %s %2d %d", days_a[range(0, timeptr->tm_wday, 6)], months_a[range(0, timeptr->tm_mon, 11)], range(1, timeptr->tm_mday, 31), timeptr->tm_year + 1900); break; case 'X': /* appropriate time representation */ sprintf(tbuf, "%02d:%02d:%02d", range(0, timeptr->tm_hour, 23), range(0, timeptr->tm_min, 59), range(0, timeptr->tm_sec, 61)); break; case 'y': /* year without a century, 00 - 99 */ i = timeptr->tm_year % 100; sprintf(tbuf, "%02d", i); break; case 'Y': /* year with century */ sprintf(tbuf, "%d", 1900 + timeptr->tm_year); break; case 'Z': /* time zone name or abbrevation */ #ifdef HAVE_TZNAME i = (daylight && timeptr->tm_isdst); /* 0 or 1 */ strcpy(tbuf, tzname[i]); #else #ifdef HAVE_TM_ZONE strcpy(tbuf, timeptr->tm_zone); #else gettimeofday(& tv, & zone); strcpy(tbuf, timezone(zone.tz_minuteswest, timeptr->tm_isdst)); #endif #endif break; #ifdef SYSV_EXT case 'n': /* same as \n */ tbuf[0] = '\n'; tbuf[1] = '\0'; break; case 't': /* same as \t */ tbuf[0] = '\t'; tbuf[1] = '\0'; break; case 'D': /* date as %m/%d/%y */ strftime(tbuf, sizeof tbuf, "%m/%d/%y", timeptr); break; case 'e': /* day of month, blank padded */ sprintf(tbuf, "%2d", range(1, timeptr->tm_mday, 31)); break; case 'r': /* time as %I:%M:%S %p */ strftime(tbuf, sizeof tbuf, "%I:%M:%S %p", timeptr); break; case 'R': /* time as %H:%M */ strftime(tbuf, sizeof tbuf, "%H:%M", timeptr); break; case 'T': /* time as %H:%M:%S */ strftime(tbuf, sizeof tbuf, "%H:%M:%S", timeptr); break; #endif #ifdef SUNOS_EXT case 'k': /* hour, 24-hour clock, blank pad */ sprintf(tbuf, "%2d", range(0, timeptr->tm_hour, 23)); break; case 'l': /* hour, 12-hour clock, 1 - 12, blank pad */ i = range(0, timeptr->tm_hour, 23); if (i == 0) i = 12; else if (i > 12) i -= 12; sprintf(tbuf, "%2d", i); break; #endif #ifdef VMS_EXT case 'v': /* date as dd-bbb-YYYY */ sprintf(tbuf, "%02d-%3.3s-%4d", range(1, timeptr->tm_mday, 31), months_a[range(0, timeptr->tm_mon, 11)], timeptr->tm_year + 1900); for (i = 3; i < 6; i++) if (islower(tbuf[i])) tbuf[i] = toupper(tbuf[i]); break; #endif #ifdef POSIX2_DATE case 'C': sprintf(tbuf, "%02d", (timeptr->tm_year + 1900) / 100); break; case 'E': case 'O': /* POSIX locale extensions, ignored for now */ goto again; case 'V': /* week of year according ISO 8601 */ #if defined(GAWK) && defined(VMS_EXT) { extern int do_lint; extern void warning(); static int warned = 0; if (! warned && do_lint) { warned = 1; warning( "conversion %%V added in P1003.2; for VMS style date, use %%v"); } } #endif sprintf(tbuf, "%02d", iso8601wknum(timeptr)); break; case 'u': /* ISO 8601: Weekday as a decimal number [1 (Monday) - 7] */ sprintf(tbuf, "%d", timeptr->tm_wday == 0 ? 7 : timeptr->tm_wday); break; #endif /* POSIX2_DATE */ default: tbuf[0] = '%'; tbuf[1] = *format; tbuf[2] = '\0'; break; } i = strlen(tbuf); if (i) { if (s + i < endp - 1) { strcpy(s, tbuf); s += i; } else return 0; } } out: if (s < endp && *format == '\0') { *s = '\0'; return (s - start); } else return 0; } /* isleap --- is a year a leap year? */ #ifndef __STDC__ static int isleap(year) int year; #else static int isleap(int year) #endif { return ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0); } #ifdef POSIX2_DATE /* iso8601wknum --- compute week number according to ISO 8601 */ #ifndef __STDC__ static int iso8601wknum(timeptr) const struct tm *timeptr; #else static int iso8601wknum(const struct tm *timeptr) #endif { /* * From 1003.2: * If the week (Monday to Sunday) containing January 1 * has four or more days in the new year, then it is week 1; * otherwise it is the highest numbered week of the previous * (52 or 53) year, and the next week is week 1. * * ADR: This means if Jan 1 was Monday through Thursday, * it was week 1, otherwise week 52 or 53. * * XPG4 erroneously included POSIX.2 rationale text in the * main body of the standard. Thus it requires week 53. */ int weeknum, jan1day, diff; /* get week number, Monday as first day of the week */ weeknum = weeknumber(timeptr, 1); /* * With thanks and tip of the hatlo to tml(a)tik.vtt.fi * * What day of the week does January 1 fall on? * We know that * (timeptr->tm_yday - jan1.tm_yday) MOD 7 == * (timeptr->tm_wday - jan1.tm_wday) MOD 7 * and that * jan1.tm_yday == 0 * and that * timeptr->tm_wday MOD 7 == timeptr->tm_wday * from which it follows that. . . */ jan1day = timeptr->tm_wday - (timeptr->tm_yday % 7); if (jan1day < 0) jan1day += 7; /* * If Jan 1 was a Monday through Thursday, it was in * week 1. Otherwise it was last year's highest week, which is * this year's week 0. * * What does that mean? * If Jan 1 was Monday, the week number is exactly right, it can * never be 0. * If it was Tuesday through Thursday, the weeknumber is one * less than it should be, so we add one. * Otherwise, Friday, Saturday or Sunday, the week number is * OK, but if it is 0, it needs to be 52 or 53. */ switch (jan1day) { case 1: /* Monday */ break; case 2: /* Tuesday */ case 3: /* Wednedsday */ case 4: /* Thursday */ weeknum++; break; case 5: /* Friday */ case 6: /* Saturday */ case 0: /* Sunday */ if (weeknum == 0) { #ifdef USE_BROKEN_XPG4 /* XPG4 (as of March 1994) says 53 unconditionally */ weeknum = 53; #else /* get week number of last week of last year */ struct tm dec31ly; /* 12/31 last year */ dec31ly = *timeptr; dec31ly.tm_year--; dec31ly.tm_mon = 11; dec31ly.tm_mday = 31; dec31ly.tm_wday = (jan1day == 0) ? 6 : jan1day - 1; dec31ly.tm_yday = 364 + isleap(dec31ly.tm_year + 1900); weeknum = iso8601wknum(& dec31ly); #endif } break; } return weeknum; } #endif /* weeknumber --- figure how many weeks into the year */ /* With thanks and tip of the hatlo to ado(a)elsie.nci.nih.gov */ #ifndef __STDC__ static int weeknumber(timeptr, firstweekday) const struct tm *timeptr; int firstweekday; #else static int weeknumber(const struct tm *timeptr, int firstweekday) #endif { int wday = timeptr->tm_wday; int ret; if (firstweekday == 1) { if (wday == 0) /* sunday */ wday = 6; else wday--; } ret = ((timeptr->tm_yday + 7 - wday) / 7); if (ret < 0) ret = 0; return ret; } #if 0 /* ADR --- I'm loathe to mess with ado's code ... */ Date: Wed, 24 Apr 91 20:54:08 MDT From: Michal Jaegermann <audfax!emory!vm.ucs.UAlberta.CA!NTOMCZAK> To: arnold(a)audiofax.com Hi Arnold, in a process of fixing of strftime() in libraries on Atari ST I grabbed some pieces of code from your own strftime. When doing that it came to mind that your weeknumber() function compiles a little bit nicer in the following form: /* * firstweekday is 0 if starting in Sunday, non-zero if in Monday */ { return (timeptr->tm_yday - timeptr->tm_wday + (firstweekday ? (timeptr->tm_wday ? 8 : 1) : 7)) / 7; } How nicer it depends on a compiler, of course, but always a tiny bit. Cheers, Michal ntomczak(a)vm.ucs.ualberta.ca #endif #ifdef TEST_STRFTIME /* * NAME: * tst * * SYNOPSIS: * tst * * DESCRIPTION: * "tst" is a test driver for the function "strftime". * * OPTIONS: * None. * * AUTHOR: * Karl Vogel * Control Data Systems, Inc. * vogelke(a)c-17igp.wpafb.af.mil * * BUGS: * None noticed yet. * * COMPILE: * cc -o tst -DTEST_STRFTIME strftime.c */ /* ADR: I reformatted this to my liking, and deleted some unneeded code. */ #ifndef NULL #include <stdio.h> #endif #include <sys/time.h> #include <string.h> #define MAXTIME 132 /* * Array of time formats. */ static char *array[] = { "(%%A) full weekday name, var length (Sunday..Saturday) %A", "(%%B) full month name, var length (January..December) %B", "(%%C) Century %C", "(%%D) date (%%m/%%d/%%y) %D", "(%%E) Locale extensions (ignored) %E", "(%%H) hour (24-hour clock, 00..23) %H", "(%%I) hour (12-hour clock, 01..12) %I", "(%%M) minute (00..59) %M", "(%%O) Locale extensions (ignored) %O", "(%%R) time, 24-hour (%%H:%%M) %R", "(%%S) second (00..61) %S", "(%%T) time, 24-hour (%%H:%%M:%%S) %T", "(%%U) week of year, Sunday as first day of week (00..53) %U", "(%%V) week of year according to ISO 8601 %V", "(%%W) week of year, Monday as first day of week (00..53) %W", "(%%X) appropriate locale time representation (%H:%M:%S) %X", "(%%Y) year with century (1970...) %Y", "(%%Z) timezone (EDT), or blank if timezone not determinable %Z", "(%%a) locale's abbreviated weekday name (Sun..Sat) %a", "(%%b) locale's abbreviated month name (Jan..Dec) %b", "(%%c) full date (Sat Nov 4 12:02:33 1989)%n%t%t%t %c", "(%%d) day of the month (01..31) %d", "(%%e) day of the month, blank-padded ( 1..31) %e", "(%%h) should be same as (%%b) %h", "(%%j) day of the year (001..366) %j", "(%%k) hour, 24-hour clock, blank pad ( 0..23) %k", "(%%l) hour, 12-hour clock, blank pad ( 0..12) %l", "(%%m) month (01..12) %m", "(%%p) locale's AM or PM based on 12-hour clock %p", "(%%r) time, 12-hour (same as %%I:%%M:%%S %%p) %r", "(%%u) ISO 8601: Weekday as decimal number [1 (Monday) - 7] %u", "(%%v) VAX date (dd-bbb-YYYY) %v", "(%%w) day of week (0..6, Sunday == 0) %w", "(%%x) appropriate locale date representation %x", "(%%y) last two digits of year (00..99) %y", (char *) NULL }; /* main routine. */ int main(argc, argv) int argc; char **argv; { long time(); char *next; char string[MAXTIME]; int k; int length; struct tm *tm; long clock; /* Call the function. */ clock = time((long *) 0); tm = localtime(&clock); for (k = 0; next = array[k]; k++) { length = strftime(string, MAXTIME, next, tm); printf("%s\n", string); } exit(0); } #endif /* TEST_STRFTIME */ EOF echo - 'date.1' cat << 'EOF' > 'date.1' .TH DATE 1 .SH NAME date \- write the date and time .SH SYNOPSIS .B date [ .B \-u ] [ .RI + format ] .SH DESCRIPTION .I Date writes the current date and time to the standard output. It is intended to be compliant with the Posix 1003.2 Command Language and Utilities standard. Therefore, it is purposely .I not usable by the super-user for setting the system time. .LP .I Date accepts one option: .TP .B \-u Perform operations as if the .B TZ environment variable was set to .BR GMT0 . .LP If an argument to .I date is given that begins with a ``+'', then the output is controlled by the contents of the rest of the string. Normal text is output unmodified, while field descriptors in the format string are substituted for. .LP The .I date program is essentially a wrapper around .IR strftime (3); see there for a description of the available formatting options. .LP If no format string is given, or if it does not begin with a ``+'', then the default format of \fB"%a %b %e %H:%M:%S %Z %Y"\fR will be used. This produces the traditional style of output, such as ``Sun Mar 17 10:32:47 EST 1991''. .SH SEE ALSO time(2), strftime(3), localtime(3) .SH BUGS This version only works for the POSIX locale. .SH AUTHOR .nf Arnold Robbins .sp INTERNET: arnold(a)skeeve.atl.ga.us UUCP: emory!skeeve!arnold Phone: +1 404 248 9324 .fi EOF echo - 'strftime.3' cat << 'EOF' > 'strftime.3' .TH STRFTIME 3 .SH NAME strftime \- generate formatted time information .SH SYNOPSIS .ft B .nf #include <sys/types.h> #include <time.h> .sp size_t strftime(char *s, size_t maxsize, const char *format, const struct tm *timeptr); .SH DESCRIPTION The following description is transcribed verbatim from the December 7, 1988 draft standard for ANSI C. This draft is essentially identical in technical content to the final version of the standard. .LP The .B strftime function places characters into the array pointed to by .B s as controlled by the string pointed to by .BR format . The format shall be a multibyte character sequence, beginning and ending in its initial shift state. The .B format string consists of zero or more conversion specifiers and ordinary multibyte characters. A conversion specifier consists of a .B % character followed by a character that determines the behavior of the conversion specifier. All ordinary multibyte characters (including the terminating null character) are copied unchanged into the array. If copying takes place between objects that overlap the behavior is undefined. No more than .B maxsize characters are placed into the array. Each conversion specifier is replaced by appropriate characters as described in the following list. The appropriate characters are determined by the .B LC_TIME category of the current locale and by the values contained in the structure pointed to by .BR timeptr . .TP .B %a is replaced by the locale's abbreviated weekday name. .TP .B %A is replaced by the locale's full weekday name. .TP .B %b is replaced by the locale's abbreviated month name. .TP .B %B is replaced by the locale's full month name. .TP .B %c is replaced by the locale's appropriate date and time representation. .TP .B %d is replaced by the day of the month as a decimal number .RB ( 01 - 31 ). .TP .B %H is replaced by the hour (24-hour clock) as a decimal number .RB ( 00 - 23 ). .TP .B %I is replaced by the hour (12-hour clock) as a decimal number .RB ( 01 - 12 ). .TP .B %j is replaced by the day of the year as a decimal number .RB ( 001 - 366 ). .TP .B %m is replaced by the month as a decimal number .RB ( 01 - 12 ). .TP .B %M is replaced by the minute as a decimal number .RB ( 00 - 59 ). .TP .B %p is replaced by the locale's equivalent of the AM/PM designations associated with a 12-hour clock. .TP .B %S is replaced by the second as a decimal number .RB ( 00 - 61 ). .TP .B %U is replaced by the week number of the year (the first Sunday as the first day of week 1) as a decimal number .RB ( 00 - 53 ). .TP .B %w is replaced by the weekday as a decimal number .RB [ "0 " (Sunday)- 6 ]. .TP .B %W is replaced by the week number of the year (the first Monday as the first day of week 1) as a decimal number .RB ( 00 - 53 ). .TP .B %x is replaced by the locale's appropriate date representation. .TP .B %X is replaced by the locale's appropriate time representation. .TP .B %y is replaced by the year without century as a decimal number .RB ( 00 - 99 ). .TP .B %Y is replaced by the year with century as a decimal number. .TP .B %Z is replaced by the time zone name or abbreviation, or by no characters if no time zone is determinable. .TP .B %% is replaced by .BR % . .LP If a conversion specifier is not one of the above, the behavior is undefined. .SH RETURNS If the total number of resulting characters including the terminating null character is not more than .BR maxsize , the .B strftime function returns the number of characters placed into the array pointed to by .B s not including the terminating null character. Otherwise, zero is returned and the contents of the array are indeterminate. .SH NON-ANSI EXTENSIONS If .B SYSV_EXT is defined when the routine is compiled, then the following additional conversions will be available. These are borrowed from the System V .IR cftime (3) and .IR ascftime (3) routines. .TP .B %D is equivalent to specifying .BR %m/%d/%y . .TP .B %e is replaced by the day of the month, padded with a blank if it is only one digit. .TP .B %h is equivalent to .BR %b , above. .TP .B %n is replaced with a newline character (\s-1ASCII LF\s+1). .TP .B %r is equivalent to specifying .BR "%I:%M:%S %p" . .TP .B %R is equivalent to specifying .BR %H:%M . .TP .B %T is equivalent to specifying .BR %H:%M:%S . .TP .B %t is replaced with a \s-1TAB\s+1 character. .PP If .B SUNOS_EXT is defined when the routine is compiled, then the following additional conversions will be available. These are borrowed from the SunOS version of .IR strftime . .TP .B %k is replaced by the hour (24-hour clock) as a decimal number .RB ( 0 - 23 ). Single digit numbers are padded with a blank. .TP .B %l is replaced by the hour (12-hour clock) as a decimal number .RB ( 1 - 12 ). Single digit numbers are padded with a blank. .SH POSIX 1003.2 EXTENSIONS If .B POSIX2_DATE is defined, then all of the conversions available with .B SYSV_EXT and .B SUNOS_EXT are available, as well as the following additional conversions: .TP .B %C The century, as a number between 00 and 99. .TP .B %u is replaced by the weekday as a decimal number .RB [ "1 " (Monday)- 7 ]. .TP .B %V is replaced by the week number of the year (the first Monday as the first day of week 1) as a decimal number .RB ( 01 - 53 ). The method for determining the week number is as specified by ISO 8601 (to wit: if the week containing January 1 has four or more days in the new year, then it is week 1, otherwise it is the highest numbered week of the previous year (52 or 53) and the next week is week 1). .LP The text of the POSIX standard for the .I date utility describes .B %U and .B %W this way: .TP .B %U is replaced by the week number of the year (the first Sunday as the first day of week 1) as a decimal number .RB ( 00 - 53 ). All days in a new year preceding the first Sunday are considered to be in week 0. .TP .B %W is replaced by the week number of the year (the first Monday as the first day of week 1) as a decimal number .RB ( 00 - 53 ). All days in a new year preceding the first Monday are considered to be in week 0. .LP In addition, the alternate representations .BR %Ec , .BR %EC , .BR %Ex , .BR %Ey , .BR %EY , .BR %Od , .BR %Oe , .BR %OH , .BR %OI , .BR %Om , .BR %OM , .BR %OS , .BR %Ou , .BR %OU , .BR %OV , .BR %Ow , .BR %OW , and .B %Oy are recognized, but their normal representations are used. .SH VMS EXTENSIONS If .B VMS_EXT is defined, then the following additional conversion is available: .TP .B %v The date in VMS format (e.g. 20-JUN-1991). .SH SEE ALSO .IR time (2), .IR ctime (3), .IR localtime (3), .IR tzset (3) .SH BUGS This version does not handle multibyte characters or pay attention to the setting of the .B LC_TIME environment variable. .LP It is not clear what is ``appropriate'' for the C locale; the values returned are a best guess on the author's part. .SH CAVEATS The pre-processor symbol .B POSIX_SEMANTICS is automatically defined, which forces the code to call .IR tzset (3) whenever the .B TZ environment variable has changed. If this routine will be used in an application that will not be changing .BR TZ , then there may be some performance improvements by not defining .BR POSIX_SEMANTICS . .SH AUTHOR .nf Arnold Robbins .sp INTERNET: arnold(a)skeeve.atl.ga.us UUCP: emory!skeeve!arnold Phone: +1 404 248 9324 .fi .SH ACKNOWLEDGEMENTS Thanks to Geoff Clare <gwc(a)root.co.uk> for helping debug earlier versions of this routine, and for advice about POSIX semantics. Additional thanks to Arthur David Olsen <ado(a)elsie.nci.nih.gov> for some code improvements. Thanks also to Tor Lillqvist <tml(a)tik.vtt.fi> for code fixes to the ISO 8601 code. EOF

1 0

Re: workaround for common programming error involving ctime and localtime
by ado May 11, 1994

May 11, 1994

> ! /* > ! ** The following is equivalent to `return asctime(localtime(timep));', > ! ** except it does not modify localtime's static storage, > ! ** and thus it works around all-too-common bugs like > ! ** `struct tm *p = localtime(&t1); puts(ctime(&t2)); return p->tm_year'. > ! */ Hmmm...given the X3J11 description of ctime in section 4.12.3.2... The ctime funciton converts the calendar time pointed to by timer to local time in the form of a string. It is equivalent to asctime(localtime(timer)) ...do we open ourselves up to standard conformance challenges if ctime is anything except "asctime(localtime(timer))"? --ado

2 1

support for ICL extension to Posix TZ string parsing
by yata!eggert＠twinsun.com May 8, 1994

May 8, 1994

The following Usenet article describes a extension to Posix TZ strings that allows the strings to express the daylight savings time rules currently used in Britain. At the end of this message is a patch to the tz package that adds support for this extension. This patch also fixes a theoretical leap second problem with Posix TZ strings. But looking at the code, I suspect that leap seconds don't work at all with Posix TZ strings; perhaps this is intentional? Newsgroups: comp.unix.unixware From: jjf(a)dsbc.icl.co.uk (J J Farrell) Subject: Re: Daylight saving time in UW1.1 Message-ID: <CpCvnG.7Dy(a)dsbc.icl.co.uk> Organization: International Computers Limited References: <767043120.AA04204(a)cswamp.apana.org.au> <Cp9x6n.7uB(a)novell.co.uk> Date: Fri, 6 May 1994 00:50:03 GMT In article <Cp9x6n.7uB(a)novell.co.uk> msohnius(a)novell.co.uk (Martin Sohnius) writes: > UnixWare supports two different styles of timezone handling. > > One is what I may call "System V" style, with the TZ environment > variable as described in environ(5). It might be better described as "Standard" style - it's been specified by X/Open for many years, and I think Posix is the same. > Note also that the October rule for many parts of Australia > ("next-to-last Sunday in October") cannot be implemented with the > "System V" style TZ. (NB nor can the British rule, > "day after 4th Saturday in October"). I'm not sure about the Australian ones, but the British rule can be done in "System V" style TZ. The following works on SVR4 systems and has been issued by ICL for several years: GMT0BST,M3.5.0/1,M10.4.6/26 I've not looked up the wording in the SVR4 documentation, but this does break the wording in XPG3; they may have loosened the wording in XPG4, but I haven't checked. It is probably a bug that this works, but bugs can sometimes be useful! My opinions; I do not speak for my employer. =================================================================== RCS file: RCS/localtime.c,v retrieving revision 1994.6.1.2 retrieving revision 1994.6.1.3 diff -c -r1994.6.1.2 -r1994.6.1.3 *** localtime.c 1994/05/09 10:16:11 1994.6.1.2 --- localtime.c 1994/05/09 10:22:51 1994.6.1.3 *************** *** 414,423 **** { int num; ! strp = getnum(strp, &num, 0, HOURSPERDAY); if (strp == NULL) return NULL; ! *secsp = num * SECSPERHOUR; if (*strp == ':') { ++strp; strp = getnum(strp, &num, 0, MINSPERHOUR - 1); --- 414,429 ---- { int num; ! /* ! ** `HOURSPERDAY * DAYSPERWEEK - 1' allows quasi-Posix rules like ! ** "M10.4.6/26", which does not conform to Posix, ! ** but which specifies the equivalent of ! ** ``02:00 on the first Sunday on or after 23 Oct''. ! */ ! strp = getnum(strp, &num, 0, HOURSPERDAY * DAYSPERWEEK - 1); if (strp == NULL) return NULL; ! *secsp = num * (long) SECSPERHOUR; if (*strp == ':') { ++strp; strp = getnum(strp, &num, 0, MINSPERHOUR - 1); *************** *** 426,432 **** *secsp += num * SECSPERMIN; if (*strp == ':') { ++strp; ! strp = getnum(strp, &num, 0, SECSPERMIN - 1); if (strp == NULL) return NULL; *secsp += num; --- 432,439 ---- *secsp += num * SECSPERMIN; if (*strp == ':') { ++strp; ! /* `SECSPERMIN' allows for leap seconds. */ ! strp = getnum(strp, &num, 0, SECSPERMIN); if (strp == NULL) return NULL; *secsp += num;

1 0

workaround for common programming error involving ctime and localtime
by yata!eggert＠twinsun.com May 8, 1994

May 8, 1994

The following patch lets the tz package work around a common programming error when using ctime and localtime. =================================================================== RCS file: RCS/localtime.c,v retrieving revision 1994.6.1.1 retrieving revision 1994.6.1.2 diff -c -r1994.6.1.1 -r1994.6.1.2 *** localtime.c 1994/05/05 16:24:49 1994.6.1.1 --- localtime.c 1994/05/09 10:16:11 1994.6.1.2 *************** *** 1136,1142 **** ctime(timep) const time_t * const timep; { ! return asctime(localtime(timep)); } /* --- 1136,1151 ---- ctime(timep) const time_t * const timep; { ! struct tm tm; ! ! /* ! ** The following is equivalent to `return asctime(localtime(timep));', ! ** except it does not modify localtime's static storage, ! ** and thus it works around all-too-common bugs like ! ** `struct tm *p = localtime(&t1); puts(ctime(&t2)); return p->tm_year'. ! */ ! localsub(timep, 0L, &tm); ! return asctime(&tm); } /*

1 0