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
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.
Peter Krantz wrote:
···
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
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
···
On Apr 28, 2006, at 7:15 AM, Peter Krantz wrote:
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?
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
http://trackmap.robotcoop.com
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.standards-schmandards.com
Eric Hodel wrote:
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?
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
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 Krantz wrote:
This isn't new, and it's not really a ruby problem:
Year 2038 problem - Wikipedia
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 ?
···
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.).
--
Ross Bamford - rosco@roscopeco.REMOVE.co.uk
"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.
···
Peter Krantz
--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org
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.standards-schmandards.com
···
On 4/29/06, Christian Neukirchen <chneukirchen@gmail.com> wrote:
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
"Peter Krantz" <peter.krantz@gmail.com> writes:
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.
···
On 4/29/06, Christian Neukirchen <chneukirchen@gmail.com> wrote:
Peter Krantz
--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org
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
···
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.