Mark Volkmann wrote:
> On 2/4/06, James Edward Gray II <james / grayproductions.net> wrote:
>   
>> On Feb 4, 2006, at 2:57 PM, Mark Volkmann wrote:
>>
>>     
>>> I'm confused about whether the Date class is built-in or in the
>>> standard library.
>>>       
>> It's a standard library.
>>
>>     
>>> I can use it without requiring it in irb, so that tells me it's
>>> built-in.
>>>       
>> Na, that tells you that irb requires it somewhere.  :)
>>     
>
> Then why does this code run?
>
> d = Date.new
> puts "d is a #{d.class}"
>
> This is telling me that there is a built-in Date class and there is
> another one in the Standard Library.
>
> ruby-doc.org documents a Date class under both the "Core API" and the
> "Standard API". They look very similar, but not identical. As I said
> earlier, pickaxe does not document it as a built-in.
>
> Why do there seem to be two Date classes?
>
> --
> R. Mark Volkmann
> Partner, Object Computing, Inc.
>   
Hi,

I wonder if you might have required rubygems at some point.  Sifting 
through rubygems:
rubygems/open-uri.rb: require 'parsedate'
parsedate.rb: require 'date/format'

So if you've got RUBYOPT set to rubygems, you'll have required rubygems 
already.  Try evaluating Date::MONTHNAMES.  This constant is set in 
date.rb and not date/format.rb so if you've only required data/format 
then you'll have a chance to hear the uninitialized constant song.

Having required rubygems would explain the presence of the Date class in 
your ruby above.

Hope that helps.  If anyone has a better idea of where the rogue Date 
might be coming from, I'd love to hear it.

Regards,
Matthew J. Desmarais

P.S.  I just realized that you'll get a good idea of what (aside from 
core) is in your ruby by evaluating $".  That's the array that holds the 
list of files that have been require'd.