Time.parse fails for year values > 2037 (time out of range)


#1

Hi!

I am trying to parse dates that take place in the future. When event
dates occur after 2038-01-01 i get an time out of range error. To
reproduce in irb:

irb(main):078:0> t = “2038-12-01T15:00:00.000Z”
=> “2038-12-01T15:00:00.000Z”

irb(main):079:0> s = “2012-12-01T15:00:00.000Z”
=> “2012-12-01T15:00:00.000Z”

irb(main):080:0> Time::parse(s)
=> Sat Dec 01 15:00:00 UTC 2012

irb(main):081:0> Time::parse(t)
ArgumentError: time out of range
from /opt/local/lib/ruby/1.8/time.rb:180:in utc' from /opt/local/lib/ruby/1.8/time.rb:180:inmake_time’
from /opt/local/lib/ruby/1.8/time.rb:243:in `parse’
from (irb):81

I am running ruby 1.8.4 (2005-12-24) [i686-darwin8.6.1].

Am I doing something wrong or is this a bug?

Kind regards,

Peter K.


#2

Looks like the Unix time limitation. Unix based OS, like darin, uses
the number of seconds since Jan 1 1970 to represent the time. In 2036
(I think in August sometime) the number of seconds that can be
reperesented in a 32 bit integer will be too large to fit. Gonna have
to hold out till 64 bit computing takes hold.

Farrel


#3

If you don’t need the time and just the date, then Date seems to have a
much wider range
than Time.


#4

On Sat, 2006-04-29 at 17:25 +0900, Peter K. wrote:

I specifically need both date and time. I find it strange that a
modern language like Ruby has this limitation. Looking at the
documentation I find no mention of this.

To mee, this is a dangerous bug. People developing applications may
not have thought about testing dates well into the future. The Time
module needs an update to cope with a wider range of data. C# for
example, handles values ranging from 12:00:00 midnight, January 1,
0001 Anno Domini (Common Era) to 11:59:59 P.M., December 31, 9999 A.D.
(C.E.).

This isn’t new, and it’s not really a ruby problem:

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

Depending on what you’re doing, couldn’t you maybe use two Times, one as
a later base than 1970, and the other as an offset ?


#5

I specifically need both date and time. I find it strange that a
modern language like Ruby has this limitation. Looking at the
documentation I find no mention of this.

To mee, this is a dangerous bug. People developing applications may
not have thought about testing dates well into the future. The Time
module needs an update to cope with a wider range of data. C# for
example, handles values ranging from 12:00:00 midnight, January 1,
0001 Anno Domini (Common Era) to 11:59:59 P.M., December 31, 9999 A.D.
(C.E.).

Regards,

Peter K.


http://www.standards-schmandards.com


#6

Eric H. wrote:

   from /opt/local/lib/ruby/1.8/time.rb:243:in `parse'

Wed Jan 01 00:00:00 PST 3000

Yes, but, BUT, you are limited to the year 2,147,485,547 on Solaris due
to INT_MAX.

I know, I know - no one ever thinks there app is going to be around that
long. But mark my words, some day Farg Fleeblebuuk of the 23rd
Plasmatic Programming Core on a remote moon in the Mixilflix Galaxy
(formerly Galaxy #13983) will be tasked with maintaining your Rails
application when suddenly…BOOM!

And then, and THEN, you’ll all be sorry!

Dan


#7

On Apr 28, 2006, at 7:15 AM, Peter K. wrote:

=> “2012-12-01T15:00:00.000Z”

I am running ruby 1.8.4 (2005-12-24) [i686-darwin8.6.1].

Am I doing something wrong or is this a bug?

Use a machine with a 64 bit time_t:

$ ruby -rtime -ve ‘p Time.parse(“3000-01-01”)’
ruby 1.8.4 (2005-12-24) [amd64-freebsd6]
Wed Jan 01 00:00:00 PST 3000


Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com


#8

“Peter K.” removed_email_address@domain.invalid writes:

I specifically need both date and time. I find it strange that a
modern language like Ruby has this limitation. Looking at the
documentation I find no mention of this.

This is not a limitation of Ruby, but of your operating system. If
you have a OS which time_t is 64-bit (e.g. 64-bit AIX), you can use
Time well beyond 2038.

To mee, this is a dangerous bug. People developing applications may
not have thought about testing dates well into the future. The Time
module needs an update to cope with a wider range of data. C# for
example, handles values ranging from 12:00:00 midnight, January 1,
0001 Anno Domini (Common Era) to 11:59:59 P.M., December 31, 9999 A.D.
(C.E.).

If you need a bigger range, check for Date and DateTime; these
libraries are a lot slower than native Time, however.


#9

Peter K. wrote:

DateTime has the same limit (I believe it uses the Time library as
well).

No.

irb(main):001:0> require ‘Date’
=> true
irb(main):002:0> s = DateTime.new()
=> #<DateTime: -1/2,0,2299161>
irb(main):003:0> s.to_s
=> “-4712-01-01T00:00:00Z”
irb(main):004:0> e = DateTime.new(5000000000, 4, 29, 11, 3, 12)
=> #<DateTime: 3287185598122129/1800,0,2299161>
irb(main):005:0> e.to_s
=> “5000000000-04-29T11:03:12Z”

Ray


#10

On 4/29/06, Christian N. removed_email_address@domain.invalid wrote:

This is not a limitation of Ruby, but of your operating system. If
you have a OS which time_t is 64-bit (e.g. 64-bit AIX), you can use
Time well beyond 2038.

I don’t agree. Other laguages typically implement this type of core
functionality independently of the OS. E.g. Python and C# both support
datetime constructs without this limitation on 32-bit systems. Making
the language dependent on OS libraries reduce portability.

If you need a bigger range, check for Date and DateTime; these
libraries are a lot slower than native Time, however.

DateTime has the same limit (I believe it uses the Time library as
well). Date does not support time.

Regards,

Peter K.


http://www.standards-schmandards.com


#11

On Saturday 29 April 2006 11:27 am, Peter K. wrote:

DateTime has the same limit (I believe it uses the Time library as
well). Date does not support time.

irb(main):001:0> require ‘date’
=> true
irb(main):002:0> long_time_from_now = DateTime.new(3006,04,29,17,5,25)
=> #<DateTime: 9742799965/3456,0,2299161>
irb(main):003:0> long_time_from_now.asctime
=> “Tue Apr 29 17:05:25 3006”

Kirk H.


#12

“Peter K.” removed_email_address@domain.invalid writes:

On 4/29/06, Christian N. removed_email_address@domain.invalid wrote:

This is not a limitation of Ruby, but of your operating system. If
you have a OS which time_t is 64-bit (e.g. 64-bit AIX), you can use
Time well beyond 2038.

I don’t agree. Other laguages typically implement this type of core
functionality independently of the OS. E.g. Python and C# both support
datetime constructs without this limitation on 32-bit systems. Making
the language dependent on OS libraries reduce portability.

Citing http://ftp.python.org/doc/lib/module-time.html:

The functions in this module do not handle dates and times before
the epoch or far in the future. The cut-off point in the future is
determined by the C library; for Unix, it is typically in 2038.

Python depends on the platform’s C library

Python however provides a native DateTime implementation since 2.3.

If you need a bigger range, check for Date and DateTime; these
libraries are a lot slower than native Time, however.

DateTime has the same limit (I believe it uses the Time library as
well). Date does not support time.

As mentioned, it does.