> 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. ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
