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.
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
If you don’t need the time and just the date, then Date seems to have a
much wider range
than Time.
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 ?
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
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
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. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
http://trackmap.robotcoop.com
“Peter K.” [email protected] 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.
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
On 4/29/06, Christian N. [email protected] 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
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.
“Peter K.” [email protected] writes:
On 4/29/06, Christian N. [email protected] 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.