- tz - lists.iana.org

AU Summer time channges (proposed).
by Robert Elz March 29, 1994

March 29, 1994

I'm not in AU right now, and haven't seen the announcementss, though there was talk of changes before I left, but I'm told there is agreement for Vic SA and Tas to switch to summer time on Oct 1, and revert to standard time Mar 31 to give exactly 6 months daylight saving (summer time really) a yearA. One would presume they'd keep the "change on a Sunday" rule, but who knows. Apparently NSW weren't impressed, but may end up changing their minds. I'm sure others in AU can give more details on this. kre

1 0

Re: EU Summer Time update [forwarded with permission]
by ado March 29, 1994

March 29, 1994

> From @doc.memex.co.uk:peter@memex.co.uk Tue Mar 29 08:03:37 1994 > Return-Path: <@doc.memex.co.uk:peter@memex.co.uk> > Received: from relay2.UU.NET by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA09181; Tue, 29 Mar 94 08:03:34 EST > Received: from young.cs.strath.ac.uk by relay2.UU.NET with SMTP > (5.61/UUNET-internet-primary) id AAwjia29244; Tue, 29 Mar 94 08:03:28 -0500 > Received: from doc.memex.co.uk by young.cs.strath.ac.uk id aa02542; > 29 Mar 94 14:02 +0100 > Received: by doc.memex.co.uk (4.1/memex_18) > id AA15065; Tue, 29 Mar 94 13:51:13 BST > Date: Tue, 29 Mar 94 13:51:13 BST > From: Peter Ilieve <peter(a)memex.co.uk> > Message-Id: <9403291251.AA15065(a)doc.memex.co.uk> > To: ado(a)elsie.nci.nih.gov > Subject: Re: EU Summer Time update > Status: RO > > > Thanks for the scoop on EU Summer Time. Is it premature to forward it to > > the time zone list? > > ... > > It is the best info available at present. My personal guess is that > nothing will be changed. I have no idea why it has taken since last > September to fail to confirm this directive, nor why it may take until > May. The first change from existing practice is not until October 95, > when the UK/Eire date is Sun>=22 rather than Sun>=23 so it is probably > safe to pass it on, even if you have to correct it later. > > > Peter

1 0

EU Summer Time update [forwarded with permission]
by ado March 29, 1994

March 29, 1994

> From @doc.memex.co.uk:peter@memex.co.uk Mon Mar 28 04:36:25 1994 > Return-Path: <@doc.memex.co.uk:peter@memex.co.uk> > Received: from relay2.UU.NET by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA12705; Mon, 28 Mar 94 04:36:22 EST > Received: from young.cs.strath.ac.uk by relay2.UU.NET with SMTP > (5.61/UUNET-internet-primary) id AAwjdu24981; Mon, 28 Mar 94 04:36:08 -0500 > Received: from doc.memex.co.uk by young.cs.strath.ac.uk id aa20721; > 28 Mar 94 10:34 +0100 > Received: by doc.memex.co.uk (4.1/memex_18) > id AA05804; Mon, 28 Mar 94 10:32:19 BST > Date: Mon, 28 Mar 94 10:32:19 BST > From: Peter Ilieve <peter(a)memex.co.uk> > Message-Id: <9403280932.AA05804(a)doc.memex.co.uk> > To: ado(a)elsie.nci.nih.gov > Subject: EU Summer Time update > Status: RO > > I now have a copy of the proposal for the 7th EC directive on summer time > arrangements (COM (93) 439 final, 27 September 1993). This is not yet > a formal directive, treat this as advance warning, some dates may still > change. > > I what looks like a triumph of British obduracy over the poor benighted > foreigners it is proposed to move to a common end date of the 4th Sunday > in October from 1997 so the foreigners will have their winter benightment > postponed by a month. The EC Commission actually asked its tame polling > organisation to conduct one of its Eurobarometer surveys which showed > `that European public opinion is very much in favour of having summer > time extended until the end of October'. > > The dates proposed are: > > 1995: last Sunday in March (26 March) to last Sunday in September (24 Sep) > (UK & Eire ending on 4th Sunday in October (22 Oct)) > 1996: last Sunday in March (31 March) to last Sunday in September (29 Sep) > (UK & Eire ending on 4th Sunday in October (27 Oct)) > 1997: last Sunday in March (30 March) to 4th Sunday in October (26 Oct) > 1998: last Sunday in March (29 March) to 4th Sunday in October (25 Oct) > > The UK/Eire end date of 22 October 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. A similar rule will be needed for all the > -Eur rules from 1997. > > Negotiations about joinging the EU have been concluded with Austria, > Finland, Norway and Sweden and if the current argument among the existing > members about consequential changes in voting rules can be resolved > they should join on 1 Jan 1995, and will presumably use the same > summer time rules as the existing members. I don't know what they do now. > > As I said, this is only a proposal at present. The EC information office > in Edinburgh could give a guesstimate of when the final version might > emerge. The Home Office guessed at the end of May. > I will keep you posted. > > > Peter Ilieve peter(a)memex.co.uk

1 0

Re: mktime() failures under PCTS testing
by Grant Sullivan March 23, 1994

March 23, 1994

In PCTS, "ambiguous" is referring to the time periods at, and 59:59 minutes after the start of daylight savings, where the time given is as if there were no transition to daylight savings 59:59 minutes before, and at the end of daylight savings, where the time given is as if there were no transition from daylight savings and tm_isdst = -1, assuming the difference between standard vs. daylight is 60:00 minutes. I've run tests on SVR4v3 and HP-UX C.09.01 systems and found their mktime() maps 02:MM:SS/DST-UNKNOWN to 01:MM:SS/DST-OFF I think I prefer 02:MM:SS/DST-UNKNOWN to 03:MM:SS/DST-ON but either mapping is acceptable to PCTS. ------- Forwarded Message Return-Path: bww+(a)transarc.com Received: from sparc51.transarc.com (sparc51.transarc.com, [192.55.207.51]) by transarc.com (5.54/3.15) id <AA06638> for grant(a)osf.org; Wed, 23 Mar 94 14:51:15 EST Received: by sparc51.transarc.com with BradMail(MH 6.8); Wed, 23 Mar 1994 14:51:06 -0500 (EST) To: Grant Sullivan <grant(a)osf.org> Cc: Arthur David Olson <ado(a)elsie.nci.nih.gov> Subject: Re: mktime() failures under PCTS testing In-Reply-To: Your message of Wed, 23 Mar 1994 13:37:01 -0500 Date: Wed, 23 Mar 1994 14:51:05 -0500 (EST) Message-Id: <16001.764452265(a)sparc51.transarc.com> From: Bradley White <bww+(a)transarc.com> > mktime() is failing only those PCTS tests which test "ambiguous" transitions > from standard to daylight time. mktime() passes all the tests for "ambiguous" > transitions from daylight to standard time, however. The first and second senses of the word "ambiguous" should be distinguished. The daylight->standard transition period does indeed include wall-clock times that each correspond to two distinct time_t's. However, the standard->daylight transition period renders wall-clock times that simply do not exist. And now my opinion: I am all for mktime() failing for *all* non-existent times-of-day, but, given that we do `isdst' correction, and map the non-existent times of ... 02:MM:SS/DST-OFF to 03:MM:SS/DST-ON and 02:MM:SS/DST-ON to 01:MM:SS/DST-OFF ..., it seems that we should also map 02:MM:SS/DST-UNKNOWN to one of those. Bradley PS: I won't mention that the test suite assumes too much about time_t's :-). ------- End of Forwarded Message

1 0

Re: mktime() failures under PCTS testing
by ado March 23, 1994

March 23, 1994

The ftpable-from-elsie version of the time zone code suffers the same fate as related by grant@osf; on our SunOS 4.1.1 system, after making this change to the sample code: > SCCS/s.try.c: 1.1 vs. 1.2 > *** 1.1/try.c Tue Mar 22 18:45:08 1994 > --- 1.2/try.c Tue Mar 22 18:45:08 1994 > *************** > *** 34,43 **** > --- 34,53 ---- > printf("mktime test: for this test, set TZ=dst0std,J057,J059\n"); > printf("current value of TZ = %s\n", getenv("TZ")); > > + #if 0 > if (setenv("TZ", TZ_value, 1) != 0) { > printf("resetting TZ failed\n"); > exit(1); > } > + #else > + { > + char buf[512]; > + > + (void) strcpy(buf, "TZ="); > + (void) strcat(buf, TZ_value); > + putenv(buf); > + } > + #endif > printf("new value of TZ = %s\n", getenv("TZ")); > > time_str.tm_year = TM_year - 1900; ...I get these results: > mktime test: PCTS/STD/LS/mktime 8.1.58_9 Assert 5.1.3 > mktime test: for this test, set TZ=dst0std,J057,J059 > current value of TZ = (null) > new value of TZ = std0dst,J057,J059 > time_str tm struct set to: > year = 91, mon = 1, mday = 26, hour = 2, min = 0, sec = 0, wday = -1, yday = -1, isdst = -1 > expected value from mktime = 667530000 >>>>> mktime returned -1 (-unknown-) > mktime() final time_str tm struct reset to: > year = 91, mon = 1, mday = 26, hour = 2, min = 0, sec = 0, wday = -1, yday = -1, isdst = -1 Vintage time zone hands will recognize this as behavior that certain SunOS versions of the "cron" program clashed with. The time zone package is assuming that the "mktime" call is asking a question such as... If US DST rules are in effect and I'm in the Eastern US, when, on April 3, 1994, will a wall clock show 2:30 a.m. (irrespective of whether it is or isn't daylight saving time)? ...and the "-1" answer is the package's way of saying... There is no such time! If someone has the relevant wording from the current version of the relevant standard(s) on what to do here, I'd love to hear from you. --ado

3 2

mktime() failures under PCTS testing [forwarded with permission]
by ado March 23, 1994

March 23, 1994

> From grant(a)osf.org Tue Mar 22 17:47:33 1994 > Return-Path: <grant(a)osf.org> > Received: from postman.osf.org by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA07444; Tue, 22 Mar 94 17:47:32 EST > Received: from vishnu.osf.org by postman.osf.org (5.64+/OSF 1.0) > id AA27681; Tue, 22 Mar 94 17:47:26 -0500 > Message-Id: <9403222247.AA27681(a)postman.osf.org> > To: ado(a)elsie.nci.nih.gov (Arthur David Olson) > Cc: grant(a)osf.org > Subject: mktime() failures under PCTS testing > Date: Tue, 22 Mar 1994 17:47:21 -0500 > From: Grant Sullivan <grant(a)osf.org> > Status: RO > > > Hi Arthur, > > I am a contractor at the Open Software Foundation, Cambridge, MA, responsible > for helping to make sure that OSF/1 R1.3 utlities and libraries are > conforming to POSIX.1, POSIX.2, XPG4, and other standards. > > My department's QA group recently completed a PCTS test of our current OSF/1 > libc, and reported to me that there were a number of mktime() failures in > PCTS STD/LS/mktime, such as the following: > > 5.<p1>.5.1.1. Preparation [4009] > Setup environment for testing. > > 5.<p1>.5.1.2. Testing [4009] > TZ is of the form: TZ=dst0std,J057,J059 > Non-leap year, one second prior to Jstart_day time. > > MESSAGE (5.<p1>.5.1.2.): > Testing local time of: Tue Feb 26 01:59:59 1991 > PCTS action taken: CONTINUE > > 5.<p1>.5.1.3. Testing [4009] > Non-leap year, at ambiguous Jstart_day time. > > MESSAGE (5.<p1>.5.1.3.): > Testing local time of: Tue Feb 26 02:00:00 1991 > PCTS action taken: CONTINUE > > ERROR (5.<p1>.5.1.3.): > Call to mktime() failed (returned -1). > PCTS action taken: CONTINUE > > ERROR (5.<p1>.5.1.3.): > Incorrect time returned by call to mktime(). > Expected: 667530000 Or: 667533600 > Actual: -1 > PCTS action taken: CONTINUE > > This particular test calls mktime() with tm_isdst set to -1, so it is expecting > mktime() to return either the standard time value (667530000), or the > daylight time value (667533600), under the apparent assumption that if > tm_isdst == -1, then mktime() would attempt to determine if tm_isdst should be > 0 or 1 and return the proper seconds, and adjust the struct tm accordingly. > > Our current OSF/1 libc ctime.c is based on BSD 4.4-alpha snapshot > "@(#)ctime.c 5.26 (Berkeley) 2/23/91" > with additional fixes from your June'93 kit: > elsieid[] = "@(#)localtime.c 7.9" > plus some other adjustments. > > There are quite a few PCTS failures, but I think they all boil down to a common > cause: mktime() returns -1 when tm_isdst = -1 and the tm structure specifies > the daylight savings time day, and a time at or within the first hour of > daylight savings time. > > I have created a simple test program, based on the XPG4 mktime() example, > which exercises the first PCTS failure case above. I've tried this on > several systems which have older versions of the Zoneinfo package, and on > several systems which don't have the package. I got the same failure on the > older Zoneinfo systems I tested, and mktime() returned 667530000, and set > tm_isdst to 0 on the several systems I tested which don't use the package. > > My own interpretation of the XPG4 and POSIX.2 standards suggest that mktime() > should return 667533600, and reset the passed tm_isdst to 1, under the belief > that for the above case, daylight savings starts exactly at > Tue Feb 26 02:00:00 1991 > for TZ=dst0std,J057,J059, instead of after this time, i.e. instead of at > Tue Feb 26 02:00:01 1991 > > A friend of mine at another company told me he had run into similar mktime() > problems with the FIPS151-2 test suite. He made alterations which resulted > in mktime() returning 667533600, and tm_isdst reset to 1, so we both have the > same interpretations of the XPG4 and POSIX.1 standards. His version of > mktime() was based on something older than your June'93 kit. > > I am wondering what mktime() in your current kit does in this case? Do you > think it should return: > > -1 , tm_isdst = -1 > or 667530000, tm_isdst = 0 > or 667533600, tm_isdst = 1 > > ? > > I am attaching a test program. > > Thanks very much for your help, > > Grant W. Sullivan, grant(a)osf.org > Open Software Foundation > 11 Cambridge Center, > Cambridge, MA 02142 > > > mktime_XPG4_example.c > ========================================================================== > /* XPG4, pg. 276 mktime() example > * > * with input data from PCTS STD/LS/mktime 8.1.58_09 5.1.3 test > * > */ > > #include <stdio.h> > #include <time.h> > > #include <stdlib.h> > > struct tm time_str; > > char daybuf[20]; > > /* values for struct tm; from PCTS STD/LS/mktime 8.1.58_09.c */ > #define TZ_value "std0dst,J057,J059" > #define TM_year 1991 /* non-leap year */ > #define TM_mon 2 /* dst start month -- February */ > #define TM_mday 26 /* dst start day J057 non-leap year */ > #define TM_hour 2 /* for J057 dst start hour */ > #define TM_min 0 /* for J057 dst start hour/min */ > #define TM_sec 0 /* for J057 dst start hour/min/sec */ > #define TM_wday -1 /* don't know */ > #define TM_yday -1 /* don't know */ > #define TM_isdst -1 /* don't know if std or dst */ > #define MKTIME_expected 667530000L > > > main() > { > time_t mktime_returned; > > printf("mktime test: PCTS/STD/LS/mktime 8.1.58_9 Assert 5.1.3\n"); > printf("mktime test: for this test, set TZ=dst0std,J057,J059\n"); > printf("current value of TZ = %s\n", getenv("TZ")); > > if (setenv("TZ", TZ_value, 1) != 0) { > printf("resetting TZ failed\n"); > exit(1); > } > printf("new value of TZ = %s\n", getenv("TZ")); > > time_str.tm_year = TM_year - 1900; > time_str.tm_mon = TM_mon - 1; > time_str.tm_mday = TM_mday; > time_str.tm_hour = TM_hour; > time_str.tm_min = TM_min; > time_str.tm_sec = TM_sec; > time_str.tm_wday = TM_wday; > time_str.tm_yday = TM_yday; > time_str.tm_isdst = TM_isdst; > > printf("time_str tm struct set to:\n year = %d, mon = %d, mday = %d, hour = %d, min = %d, sec = %d, wday = %d, yday = %d, isdst = %d\n", > time_str.tm_year, time_str.tm_mon, time_str.tm_mday, time_str.tm_hour, time_str.tm_min, time_str.tm_sec, time_str.tm_wday, time_str.tm_yday, time_str.tm_isdst); > printf("expected value from mktime = %d\n", MKTIME_expected); > > if ((mktime_returned = mktime(&time_str)) == (time_t)-1) { > (void)puts("mktime returned -1 (-unknown-)"); > printf("mktime() final time_str tm struct reset to:\n year = %d, mon = %d, mday = %d, hour = %d, min = %d, sec = %d, wday = %d, yday = %d, isdst = %d\n", > time_str.tm_year, time_str.tm_mon, time_str.tm_mday, time_str.tm_hour, time_str.tm_min, time_str.tm_sec, time_str.tm_wday, time_str.tm_yday, time_str.tm_isdst); > exit(1); > } > else { > printf("mktime returned value = %d\n", (int) mktime_returned); > printf("mktime() final time_str tm struct reset to:\n year = %d, mon = %d, mday = %d, hour = %d, min = %d, sec = %d, wday = %d, yday = %d, isdst = %d\n", > time_str.tm_year, time_str.tm_mon, time_str.tm_mday, time_str.tm_hour, time_str.tm_min, time_str.tm_sec, time_str.tm_wday, time_str.tm_yday, time_str.tm_isdst); > > (void)strftime(daybuf, sizeof(daybuf), "%A", &time_str); > (void)puts(daybuf); > } > > exit(0); > } > ==========================================================================

2 1

Re: Does anyone have the source for this function?
by myersn＠roguewave.com March 23, 1994

March 23, 1994

> Does anyone have a UNIX function for converting a time from timezoneX > to timezoneY? I know how to write this by mucking with char** environ > and by calling tzset(), but I'm interested in a more elegant solution > (perhaps using fields in the tm structure). > > convert(timezoneX, timezoneY, inputTime, outputTime) > > The char** environ solution seems to me to be inelegant because > > 1) I have to reread a file whenever I call tzset() (I think), > and > > 2) while I'm doing the conversion the call to tzset() has a > global effect on my process. If I'm interrupted by a > signal handler that displays the time it will be in a > foreign timezone. My current best solution is to use the Rogue Wave Tools.h++ library class RWZone. Nathan Myers myersn(a)roguewave.com

1 0

Does anyone have the source for this function?
by aaron＠lehman.com March 22, 1994

March 22, 1994

Does anyone have a UNIX function for converting a time from timezoneX to timezoneY? I know how to write this by mucking with char** environ and by calling tzset(), but I'm interested in a more elegant solution (perhaps using fields in the tm structure). convert(timezoneX, timezoneY, inputTime, outputTime) The char** environ solution seems to me to be inelegant because 1) I have to reread a file whenever I call tzset() (I think), and 2) while I'm doing the conversion the call to tzset() has a global effect on my process. If I'm interrupted by a signal handler that displays the time it will be in a foreign timezone. aaron(a)lehman.com

1 0

Time Conversoin Question [forwarded with permission]
by ado March 21, 1994

March 21, 1994

> From aaron(a)lehman.com Thu Mar 17 16:49:11 1994 > Return-Path: <aaron(a)lehman.com> > Received: from lehman.com by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA28619; Thu, 17 Mar 94 16:49:08 EST > Received: from relay.lehman.com by lehman.com (8.6.4/LB 0.1) > id QAA19119; Thu, 17 Mar 1994 16:48:58 -0500 > Received: from killer.lehman.com by relay.lehman.com (4.1/LB-0.6) > id AA04769; Thu, 17 Mar 94 16:48:51 EST > Received: from yen.lehman.com by killer.lehman.com (5.0/SMI-SVR4) > id AA29096; Thu, 17 Mar 1994 16:48:48 +0500 > Date: Thu, 17 Mar 1994 16:48:48 +0500 > From: aaron(a)lehman.com (Aaron Akman) > Message-Id: <9403172148.AA29096(a)killer.lehman.com> > Received: by yen.lehman.com (4.1/SMI-4.1) > id AA03187; Thu, 17 Mar 94 16:48:45 EST > To: ado(a)elsie.nci.nih.gov > Subject: Time Conversion Question > Content-Length: 1037 > Status: RO > > Arthur, > > I've downloaded your timezone stuff (got pointers from Arnold Robbins > and Don Libes), and have a question: > > I'm looking to convert from GMT to one of a few timezones, or from one > timezone to another. I'm concerned about setting TZ and calling > tzset() because I think it changes some global state associated with > the process. If I were interrupted before setting TZ back and > re-calling tzset(), I could have an interrupt function that doesn't > have the right local TZ setting. I.e. > > get_other_local_time(char* tzsetting) > { > oldsetting = temporarily_set_TZ(tzsetting); > tzset(); > > do_time_stuff_with_alternate_TZ(); > > /* i could get interrupted here by a signal handler > that needs the real local time!! */ > > set_TZ_back(oldsetting); > tzset(); > } > > Is there a better way? Is it true the effect of tzset() global? I > haven't gone through the .c files in depth yet. > > It seems like this should be a common problem for a globally > distributed system. > > Thanks in advance for any advice, > Aaron Akman > aaron(a)lehman.com > 212 464 3978

1 0

%V [forwarded]
by ado Feb. 28, 1994

Feb. 28, 1994

> From arnold(a)skeeve.atl.ga.us Sat Feb 26 21:12:21 1994 > Received: from emory.mathcs.emory.edu by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA18459; Sat, 26 Feb 94 21:12:18 EST > Received: from skeeve.UUCP by > emory.mathcs.emory.edu (5.65/Emory_mathcs.3.4.19) via UUCP > id AA09626 ; Sat, 26 Feb 94 21:12:14 -0500 > Return-Path: arnold(a)skeeve.atl.ga.us > Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) > id <m0paal5-00013rC(a)skeeve.atl.ga.us>; Sat, 26 Feb 94 20:57 EST > Message-Id: <m0paal5-00013rC(a)skeeve.atl.ga.us> > From: arnold(a)skeeve.atl.ga.us > Date: Sat, 26 Feb 1994 20:57:26 -0500 > X-Ultrix: Just Say NO! > X-Important-Saying: Premature Optimization Is The Root Of All Evil. > X-Mailer: Mail User's Shell (7.2.5 10/14/92) > To: ado(a)elsie.nci.nih.gov > Subject: any comment on this? > Status: RO > > --- Forwarded mail from Tor Lillqvist <emory!tik.vtt.fi!tml> > > >From emory!tik.vtt.fi!tml Wed Feb 23 08:12:20 1994 > Return-Path: <emory!tik.vtt.fi!tml> > Received: by skeeve.atl.ga.us (/\==/\ Smail3.1.22.1 #22.1) > id <m0pZJNz-00013zC(a)skeeve.atl.ga.us>; Wed, 23 Feb 94 08:12 EST > Received: from tiuhti.tik.vtt.fi by > emory.mathcs.emory.edu (5.65/Emory_mathcs.3.4.19) via SMTP > id AA26972 ; Wed, 23 Feb 94 08:07:40 -0500 > Received: from localhost (tml@localhost) by tiuhti.tik.vtt.fi (8.6.5/8.6.5) id PAA28498; Wed, 23 Feb 1994 15:07:33 +0200 > Date: Wed, 23 Feb 1994 15:07:33 +0200 > From: Tor Lillqvist <emory!tik.vtt.fi!tml> > Message-Id: <199402231307.PAA28498(a)tiuhti.tik.vtt.fi> > To: arnold(a)skeeve.atl.ga.us (Arnold Robbins) > In-Reply-To: arnold(a)skeeve.atl.ga.us's message of 22 Feb 1994 17:21:29 -0800 > Subject: v27i207: strftime-6.0 - yet another strftime(3) and date(1), Part01/01 > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > >>>>> On 22 Feb 1994 17:21:29 -0800, arnold(a)skeeve.atl.ga.us (Arnold Robbins) said: > > (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 > > week 53 of the previous year and the next week is week 1). > > Nope, it can also be week 52 of the previous year. For instance this > year's (1994) January 1st an 2nd were in week 52 of 1993. "The highest > numbered week of the previous year (52 or 53)" would be more correct. > > I guess you really need a format character for "what year does the > week number output by %V refer to", also. Otherwise it's hard to find > any good use for the %V format in a program or script. If, for > instance, you use `date +%V` to form the name of a weekly log file > accumulated daily, then the logging from January 1 and 2 in 1994 > should go to the log file for week 52 of 1993, not to the log file for > week 52 of 1994... > > > --- End of forwarded message from Tor Lillqvist <emory!tik.vtt.fi!tml>

1 0