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
on 28.04.2006 16:17
on 28.04.2006 16:29
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
on 29.04.2006 05:50
If you don't need the time and just the date, then Date seems to have a much wider range than Time.
on 29.04.2006 10:28
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
on 29.04.2006 11:10
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 ?
on 03.05.2006 18:58
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
on 03.05.2006 18:59
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
on 03.05.2006 19:08
"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.
on 03.05.2006 19:09
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
on 03.05.2006 19:09
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
on 03.05.2006 19:09
"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.
on 03.05.2006 19:09
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