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)
Received: Sun, 11 Apr 2004 00:49:16 +0900
And lo, xor wrote:
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
Gregory Millam wrote:
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…
Gregory Millam walker@lethalcode.net wrote in message news:20040410123059.5523c204@ozymandias.lethalcode.net…
Received: Sun, 11 Apr 2004 00:49:16 +0900
And lo, xor wrote: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
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 ?
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
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
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
From: “xor” zzqzpfynevsei@mailinator.com
Seconds count from January 1, 1970. And because of 32 bit limitations
on most systems, that means a last possible date of January 18, 2038True 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…
require ‘date’
=> true
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
Not every 64 bit OS has a 64 bit time_t (the C type for time). FreeBSD
only recently switched to a 64 bit time_t on 64 bit processors (i386
still uses a 32 bit time_t) and this is only in the -CURRENT branch.
xor (zzqzpfynevsei@mailinator.com) wrote:
Does this mean that Ruby programs running on a 64 bit OS may fail on a
32 bit OS?
–
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
Wrote Dick Davies rasputnik@hellooperator.net, on Sun, Apr 11, 2004 at 01:39:08AM +0900:
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 sroberts@certicom.com