Time upper limit
xor
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
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
Dick Davies
> Received: Sun, 11 Apr 2004 00:49:16 +0900
> And lo, xor wrote:
>> @someTime = Time.utc(2100)
>>I am getting
>> in `utc': time out of range (ArgumentError)
> 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
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
>>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
Bill Kelly
From: "xor" <zzqzpf...@mailinator.com>
> 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
>> require 'date'
=> true
>> d = Date.parse "2050-04-10"
=> #<Date: 4939813/2,0,2299161>
>> d.to_s
=> "2050-04-10"
>> d.day
=> 10
>> d.month
=> 4
>> d.year
=> 2050
>> d.strftime "%a/%A, %b/%B, %c"
=> "Sun/Sunday, Apr/April, Sun Apr 10 00:00:00 2050"
You can also get "seconds since Unix epoch" from a date
object like:
>> Date.parse("2004-04-10").strftime "%s"
=> "1081555200"
>> Time.at(1081555200).utc
=> Sat Apr 10 00:00:00 UTC 2004
Hope this helps,
Bill
Kero
> > 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....
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
--
wanna keep developing software?
http://demo.ffii.org/
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
--
Sam Roberts <srob...@certicom.com>