From owner-freebsd-bugs Thu Jun 21 1:20:10 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 97BAB37B403 for ; Thu, 21 Jun 2001 01:20:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.3/8.11.3) id f5L8K2V68634; Thu, 21 Jun 2001 01:20:02 -0700 (PDT) (envelope-from gnats) Date: Thu, 21 Jun 2001 01:20:02 -0700 (PDT) Message-Id: <200106210820.f5L8K2V68634@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Ruslan Ermilov Subject: Re: bin/28313: /bin/date -f is broken Reply-To: Ruslan Ermilov Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR bin/28313; it has been noted by GNATS. From: Ruslan Ermilov To: maxim@macomnet.ru Cc: bug-followup@FreeBSD.org Subject: Re: bin/28313: /bin/date -f is broken Date: Thu, 21 Jun 2001 11:16:20 +0300 On Thu, Jun 21, 2001 at 11:22:27AM +0400, maxim@macomnet.ru wrote: > > /bin/date -f is broken. Please take a look at > How-To-Repeat section. > > # date 200105310101 > Thu May 31 01:01:00 MSD 2001 > $ date -j -f "%m" 2 "+%b" > Mar > $ date -j -f "%m" 3 "+%b" > Mar > > Here is my hack, but AFAIK ru@freebsd.org has a more generic solution. > > --- date.c.orig Thu May 31 05:59:07 2001 > +++ date.c Thu May 31 05:58:31 2001 > @@ -192,6 +192,7 @@ > > if (fmt != NULL) { > lt = localtime(&tval); > + lt->tm_mday = 1; > t = strptime(p, fmt, lt); > if (t == NULL) { > fprintf(stderr, "Failed conversion of ``%s''" > The below patch would do the trick, but I'm not sure this is the right thing. This will "fold" tm_mday into the largest possible for this tm_year and tm_mon, instead of current "add-with-carry" operation. Both ISO C and POSIX are silent on this, and only mention that "the original values of the tm_wday and tm_yday components of the structure are ignored, and the original values of the other components are not restricted to the ranges described in ", and that "upon successful completion, the values of the tm_wday and tm_yday components of the structure shall be set appropriately, and the other components are set to represent the specified time since the Epoch, but with their values forced to the ranges indicated in the entry; the final value of tm_mday shall not be set until tm_mon and tm_year are determined." It is unspecified as to whether the implementation should "add-with-the-carry" or "fold" the values that are out of range. Both OpenBSD and NetBSD behave the same, as we share the same code. Linux behaves the same: : If structure members are outside their legal interval, they : will be normalized (so that, e.g., 40 October is changed into : 9 November). System V Release 5 behaves the same: : The original values of the components may be either greater than or : less than the specified range. For example, a tm_hour of -1 means 1 : hour before midnight, tm_mday of 0 means the day preceding the current : month, and tm_mon of -2 means 2 months before January of tm_year. SUSv2 simply derived their mktime() from POSIX.1-1988. It sounds to me that we should document the "add-with-carry" behavior and leave things AS IS. Index: localtime.c =================================================================== RCS file: /home/ncvs/src/lib/libc/stdtime/localtime.c,v retrieving revision 1.28 diff -u -p -r1.28 localtime.c --- localtime.c 2001/06/05 20:13:28 1.28 +++ localtime.c 2001/06/21 07:42:27 @@ -1440,12 +1440,16 @@ int * const okayp; i = mon_lengths[isleap(yourtm.tm_year)][yourtm.tm_mon]; if (yourtm.tm_mday <= i) break; +#if 0 yourtm.tm_mday -= i; if (++yourtm.tm_mon >= MONSPERYEAR) { yourtm.tm_mon = 0; if (increment_overflow(&yourtm.tm_year, 1)) return WRONG; } +#else + yourtm.tm_mday = i; +#endif } if (increment_overflow(&yourtm.tm_year, -TM_YEAR_BASE)) return WRONG; -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message