Ah bug I pointed out in ruby-core:8609
currently there is following error.
-:1:in `each': can't iterate from Time (TypeError)
	from -:1:in `include?'
	from -:1:in `include?'
	from -:1:in `==='
	from -:1:in `<main>'

Anyway what is worse (Time.now - 1000000 .. Time.now) === (Time.now - 3)
returns false as it enumerates Times and third time is usualy few
microseconds off. 

To me === expected behaviour is that (a..b)===c should call c.between?(a,b).

Problem at this time was that matz wanted in 1.9 ("a1".."a11") === "a9"
return true (which in 1.8 returns false.
This also could be slow for example for ("a1".."a1000000000") === "ab"

My proposal was call between and redefine String#between to do desired 
comparison as in patch attached at ruby-core:8609
BTW patch is more general than one-char comparsion as is in
range_include


On Sun, Jun 26, 2011 at 04:43:06PM +0900, Hiroshi NAKAMURA wrote:
> 
> Issue #1650 has been updated by Hiroshi NAKAMURA.
> 
> Target version set to 1.9.3
> 
> 
> ----------------------------------------
> Bug #1650: Time range === is slow
> http://redmine.ruby-lang.org/issues/1650
> 
> Author: Dmitry Bilunov
> Status: Assigned
> Priority: Normal
> Assignee: Akira Tanaka
> Category: DOC
> Target version: 1.9.3
> ruby -v: ruby 1.9.1p129 (2009-05-12 revision 23412) [x86_64-linux]
> 
> 
> =begin
>  The following program runs N times slower in ruby19 compared to ruby18.
>  N depends on the input range size.
>  
>  dev@rails ~ $ time ruby19 -rtime -e '(Time.now - 1000000 .. Time.now) === (Time.now - 3)'
>  
>  real    0m0.723s
>  user    0m0.709s
>  sys     0m0.013s
>  dev@rails ~ $ time ruby18 -rtime -e '(Time.now - 1000000 .. Time.now) === (Time.now - 3)'
>  
>  real    0m0.043s
>  user    0m0.039s
>  sys     0m0.005s
> =end
> 
> 
> 
> -- 
> http://redmine.ruby-lang.org

-- 

Network failure -  call NBC