Date: Thu, 21 Jun 2001 03:10:04 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/28313: /bin/date -f is broken Message-ID: <200106211010.f5LAA4c89342@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/28313; it has been noted by GNATS.
From: Bruce Evans <bde@zeta.org.au>
To: Ruslan Ermilov <ru@FreeBSD.ORG>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/28313: /bin/date -f is broken
Date: Thu, 21 Jun 2001 20:06:45 +1000 (EST)
On Thu, 21 Jun 2001, Ruslan Ermilov wrote:
> 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 <time.h>",
> 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 <time.h> entry; the final value of tm_mday shall
> not be set until tm_mon and tm_year are determined."
ISO C is fuzzier than I remembered about this, but POSIX.1 is unsilent
and clearly requires "add-with-carry" behaviour. From the 200x version:
25103 The relationship between the tm structure (defined in
the <time.h> header) and the time in
25104 seconds since the Epoch is that the result shall be as
specified in the expression given in the
25105 definition of seconds since the Epoch (see the Base
Definitions volume of IEEE Std 1003.1-200x,
25106 Section 4.14, Seconds Since the Epoch) corrected for
timezone and any seasonal time
25107 adjustments, where the names in the structure and in
the expression correspond.
Previous lines say the same things as the part of the ISO C standard that
you quoted. In particular, most of the components of the tm struct are
not restricted in the usual way. The above applies even to such values
and is equivalent to specifiying "add-with-carry" behaviour.
> It sounds to me that we should document the "add-with-carry" behavior
> and leave things AS IS.
I agree. Not as in your patch :-).
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106211010.f5LAA4c89342>