Out of range on Dates beyond 2038/01/19

Ruby
#1

Hi people,

I’d just found this issue trying to parse a date:

Time.local(2038, 1, 19)
=> Tue Jan 19 00:00:00 +0100 2038

Time.local(2038, 1, 20)
ArgumentError: time out of range
from (irb):33:in `local’
from (irb):33

It looks like Time class is not available to manage dates bigger than
2038/01/19.

I have found this conversation:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/190564

There they say that is a problem of 32bits processors because the number
of seconds from 1970 don’t fix into 32 bits.

Some one of you have already fight with this issue?

Is there any solution?

Thanks
f.

#2

On Thu, 11 Dec 2008 13:58:05 +0100, Fernando G.
[email protected] wrote:

Time.local(2038, 1, 19)
=> Tue Jan 19 00:00:00 +0100 2038

Time.local(2038, 1, 20)
ArgumentError: time out of range
from (irb):33:in `local’
from (irb):33

It looks like Time class is not available to manage dates bigger than
2038/01/19.

Being a user of 64 bit operating systems for over a decade now
(initially on Digital Unix), I sometimes find it surprising that so many
people are still using 32 bit operating systems. On my 64 bit Fedora
there is no issue with that date:

Time.local(2038, 1, 19)
=> Tue Jan 19 00:00:00 0100 2038

Time.local(2038, 1, 20)
=> Wed Jan 20 00:00:00 0100 2038

$ uname -a
Linux pen2.homeunix.net 2.6.27.5-41.fc9.x86_64 #1 SMP Thu Nov 13
20:29:07 EST 2008 x86_64 x86_64 x86_64 GNU/Linux

Josef ‘Jupp’ Schugt

#3

On Thu, Dec 11, 2008 at 6:58 AM, Fernando G.
[email protected] wrote:

It looks like Time class is not available to manage dates bigger than
2038/01/19.

I have found this conversation:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/190564
It’s not a ruby bug per say, it’s a general problem that 32bit systems
have with unix time. Unix time is stored in seconds since the epoch,
in a native unsigned integer, which on most systems is 32 bits. On
64bit systems, this obviously isn’t a problem.

See the link for details.

http://en.wikipedia.org/wiki/Year_2038_problem

#4

Thank you people for the information.

So the solution is to upgrade hardware to 64bits :slight_smile:

I am using Mac OS X 10.5.5

$ uname -a
Darwin macbook-de-fernando-guillen.local 9.5.0 Darwin Kernel Version
9.5.0: Wed Sep 3 11:29:43 PDT 2008; root:xnu-1228.7.58~1/RELEASE_I386
i386

Thanks again

f.

#5

Err, I should have mentioned, many UNIX and UNIX like systems have
switched to using a 64bit integer, even some running on 32 bit
processors I believe (but don’t quote me on that).

#6

Peña, Botp wrote:

require “date”

Wich is the gem I have to install?

$ gem search -r date | wc -l
42

Thanks

f.

#7

Fernando G. wrote:

Peña, Botp wrote:

require “date”

Wich is the gem I have to install?

$ gem search -r date | wc -l
42

Thanks

f.

Date is in the standard library; so no gem to install.

hth,

Siep

#8

From: Fernando G. [mailto:[email protected]]

So the solution is to upgrade hardware to 64bits :slight_smile:

you can use date. virtually no limit.

require “date”
=> true
DateTime.new(2038, 1, 20).to_s
=> “2038-01-20T00:00:00+00:00”

#9

Siep K. wrote:

Date is in the standard library; so no gem to install.

Sorry… thx… I was confused because:

require ‘date’
=> false

It works:

DateTime.new(8888,12,12).to_s
=> “8888-12-12T00:00:00+00:00”

Thanks

f.

#10

On Fri, Dec 12, 2008 at 11:52 AM, Fernando G.
[email protected] wrote:

Peña, Botp wrote:

require “date”

Wich is the gem I have to install?

$ gem search -r date | wc -l
42
That is on purpose of course :wink:
R.