Re: Time upper limit

xor wrote:
>>This isn't a ruby thing, it's a system thing.
>>
>>Seconds count from January 1, 1970. And because of 32 bit limitations on most systems, that means a last possible date of January 18, 2038
> 
> Ahem.... why is it a system thing? I am new to Ruby, so I may be
> missing something.
> Other cross platform languages do not have this limitation, in Java,
> the following runs
> fine on WindowsXP:  Data d = new Date(10000,1,1) 
> 
> Does this mean that Ruby programs running on a 64 bit OS may fail on a
> 32 bit OS?
> And how does one goes about representing the year 2050 in Ruby? 
> 
> Sorry about all those questions, last one, where is this behavior
> documented ?

In Unix circles, January 18, 2038 is known as the "end of time."
Think of it as a Y2.038K problem.  :)

It's a C/Unix thing -- not sure where it originated, as the language and
the OS are rather intertwined.

Ruby's Time class is really little more than a wrapper for the
corresponding functionality in C. I assume this is for simplicity's
sake.

This is starting to change, of course, because processors are getting
wider.

The fact is, most people most of the time do not deal with times outside
the range 1970-2038. Dates, maybe, but not times.

As for dates, you can use the Date class to get dates in a much wider
range, over thousands of years. But it doesn't do time of day.

The DateTime class is sort of a compromise between the two, but it is
imperfect.

To tell the truth, dates and times are very problematic in computing in
general -- especially with regard to time zones, and worse, Daylight
Saving Time, and worst of all, leap seconds.

But go read about Date -- it might be more what you want. As for
DateTime, it is newer, and I'm not sure where it's officially documented
yet.


HTH,
Hal