Forum: Ruby time.parse fails for year values > 2037 (time out of range)

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
F2749ed0e8e8c1a84e5ab57b45c61503?d=identicon&s=25 Peter Krantz (Guest)
on 2006-04-28 16:17
(Received via mailing list)
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:in `make_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 Krantz
05be5d6610e2c3f1780aa0e39e902e93?d=identicon&s=25 Farrel Lifson (Guest)
on 2006-04-28 16:29
(Received via mailing list)
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
C31c7255fa4488dfc5d766403b497a36?d=identicon&s=25 Jim Morris (wolfmanjm)
on 2006-04-29 05:50
(Received via mailing list)
If you don't need the time and just the date, then Date seems to have a
much wider range
than Time.
F2749ed0e8e8c1a84e5ab57b45c61503?d=identicon&s=25 Peter Krantz (Guest)
on 2006-04-29 10:28
(Received via mailing list)
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 Krantz
http://www.peterkrantz.com
http://www.standards-schmandards.com
A9b6a93b860020caf9d2d1d58c32478f?d=identicon&s=25 Ross Bamford (Guest)
on 2006-04-29 11:10
(Received via mailing list)
On Sat, 2006-04-29 at 17:25 +0900, Peter Krantz 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 ?
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2006-05-03 18:58
(Received via mailing list)
On Apr 28, 2006, at 7:15 AM, Peter Krantz 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 Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Aee77dba395ece0a04c688b05b07cd63?d=identicon&s=25 Daniel Berger (Guest)
on 2006-05-03 18:59
(Received via mailing list)
Eric Hodel 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
7264fb16beeea92b89bb42023738259d?d=identicon&s=25 Christian Neukirchen (Guest)
on 2006-05-03 19:08
(Received via mailing list)
"Peter Krantz" <peter.krantz@gmail.com> 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.
F2749ed0e8e8c1a84e5ab57b45c61503?d=identicon&s=25 Peter Krantz (Guest)
on 2006-05-03 19:09
(Received via mailing list)
On 4/29/06, Christian Neukirchen <chneukirchen@gmail.com> 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 Krantz

http://www.peterkrantz.com
http://www.standards-schmandards.com
E28c35323f624b8b9ed8712e25105454?d=identicon&s=25 Ray Baxter (Guest)
on 2006-05-03 19:09
(Received via mailing list)
Peter Krantz 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
7264fb16beeea92b89bb42023738259d?d=identicon&s=25 Christian Neukirchen (Guest)
on 2006-05-03 19:09
(Received via mailing list)
"Peter Krantz" <peter.krantz@gmail.com> writes:

> On 4/29/06, Christian Neukirchen <chneukirchen@gmail.com> 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.
1b5341b64f7ce0244366eae17f06c801?d=identicon&s=25 Kirk Haines (Guest)
on 2006-05-03 19:09
(Received via mailing list)
On Saturday 29 April 2006 11:27 am, Peter Krantz 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 Haines
This topic is locked and can not be replied to.