> On 22 May 2002, Ulrich Drepper wrote:
>
> > On Wed, 2002-05-22 at 11:23, Tom Lane wrote:
> >
> > > Unix systems have
> > > *always* interpreted time_t as a signed offset from the epoch.
> >
> > No. This always was an accident if it happens.
> >
> > > Do you
> > > really think that when Unixen were first built in the early 70s, there
> > > was no interest in working with pre-1970 dates? Hardly likely.
> >
> > There never were files or any system events with these dates. Yes.
> >
> > And just to educate you and your likes: the majority of systems on this
> > planet use mktime this way. I hate using this as an argument, but
> > beside major Unixes M$ systems also do this.
>
> M$ systems crashes regularly too ... is Redhat going to adopt that too?
Harbison and Steele indicates that:
"Although the traditional return type of time is long, the value returned is
usually of type unsigned long."
That is NOT a "Linux" reference; it was published before Linus had started
working on his kernel project.
ANSI does not indicate that time_t is a signed int, signed long, or whatever.
It is only defined to be an arithmetic type.
It would not be a bug for GLIBC to define time_t to be an unsigned int, with
an epoch beginning of January 1, 1999. That definition would conform to ANSI
C.
Since that definition can conform to ANSI C, and Unix systems have more
particularly been known to use unsigned ints with epoch of 1970, it is NOT
reasonable to assume that time_t can be used to express dates that are at all
ancient in the past.
Indeed, it is fairly _useful_ for different libc implementations to make
different assumptions about things whose definitions are permitted to vary, as
this makes it easier to call out as WRONG those systems that make up their own
definitions.
People will no doubt get defensive about their own non-standard
implementations of things; it is certainly far easier to cry "They're trying
to play Microsoft!" than it is to be honest and actually look at the standards.
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www.cbbrowne.com/info/advocacy.html
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
--
(reverse (concatenate 'string "gro.mca@" "enworbbc"))
http://www.cbbrowne.com/info/linuxxian.html
As of next Monday, COMSAT will be flushed in favor of a string and two tin
cans. Please update your software.
