On Mon, Aug 02, 2004 at 10:51:51AM +0200, Michael Neumann wrote:
> Brian Candler wrote:
> >On Sun, Aug 01, 2004 at 09:07:15PM +0200, Michael Neumann wrote:
> >
> >>okay, but:
> >>
> >> Time.local(1900) #=> time out of range
> >
> >
> >Hmm, why is that? Does Time not work with Bignums?
> >
> >OK, seems that there's a limit to 1902..2038 then.
>
> hm, wasn't UNIX time from 1970-2038?
No. Unix time is simply an offset in seconds from midnight 1st January 1970
UCT. Nobody said it could not be negative, nor how high it could go.
However on systems where time_t is a 32-bit signed integer, this gives a
limit of
$ date -r -2147483648
Fri Dec 13 20:45:52 GMT 1901
$ date -r 2147483647
Tue Jan 19 03:14:07 GMT 2038
> This are 68 years, exactly the same
> number of years as it is from 1902 to 1970... it seems that they now
> simply use internally one bit more (a real C integer instead of a Ruby
> Fixnum with only 31 bits including the sign bit?).
A C 'integer' does not have a defined length, except that it must have at
least 16 bits.
If they were using a 31-bit signed number, then it would have failed at
$ date -r 1073741824
Sat Jan 10 13:37:04 GMT 2004
I imagine that they are still using a 32-bit representation so that they can
call the underlying O/S time conversion functions (gmtime, mktime etc). This
is arguably a lazy thing to do :-)
Regards,
Brian.
|
