Time upper limit

[xor]

What are the upper limit on the values for Time class and where are they documented?

for:
@someTime = Time.utc(2100)
I am getting
in `utc': time out of range (ArgumentError)

On the other hand
@someTime = Time.utc(2020)
does not generate any errors.

(New to Ruby)

 

[Gregory Millam]

Received: Sun, 11 Apr 2004 00:49:16 +0900

What are the upper limit on the values for Time class and where are they documented?

for:
@someTime = Time.utc(2100)
I am getting
in `utc': time out of range (ArgumentError)

On the other hand
@someTime = Time.utc(2020)
does not generate any errors.

(New to Ruby)

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

 

[Dick Davies]

Received: Sun, 11 Apr 2004 00:49:16 +0900
And lo, 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

True enough - but how *do* you represent times after 2038, then?
Integers are usually 32-bit, but we can still use higher values and Ruby
will work round the platform limitations....

 

[xor]

Received: Sun, 11 Apr 2004 00:49:16 +0900



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 ?

 

[Hal Fulton]

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

 

[Bill Kelly]

Hi,

And how does one goes about representing the year 2050 in Ruby?

The date class might be more what you're looking for?

irb --simple-prompt=> "Sun/Sunday, Apr/April, Sun Apr 10 00:00:00 2050"

You can also get "seconds since Unix epoch" from a date
object like:=> "1081555200"
=> Sat Apr 10 00:00:00 UTC 2004


Hope this helps,

Bill

 

[Kero]

Seconds count from January 1, 1970. And because of 32 bit limitations

True enough - but how *do* you represent times after 2038, then?
Integers are usually 32-bit, but we can still use higher values and Ruby
will work round the platform limitations....

irb> require 'date'
=> true
irb> Date.new(2100, 5, 31).next.to_s
=> "2100-06-01"

Since I don't believe anyone knows when Daylight Savings Time will start
after 2038, I don't expect you need the hours, minutes and seconds

Happy Easter!
Kero

 

[Sam Roberts]

True enough - but how *do* you represent times after 2038, then?

In ruby1.8, do require 'date', and use DateTime. It does basically what
Time does, minus support for DST, and with a different API.

Cheers,
Sam