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.