A new gem just released by one of the RubyInstaller contributors generated this:

http://groups.google.com/group/rubyinstaller/msg/6a0b05d51811f5bc

A simple gem, generated with Ruby 1.9.2 causes date to be generated incorrectly:

Ruby 1.9.2 with RubyGems 1.8.1
date: 2011-05-07 00:00:00.000000000Z

Ruby 1.8.7 with RubyGems 1.8.1:
date: 2011-05-07 00:00:00 Z

Installing that gem causes this:

Invalid gemspec in [C:/Users/Luis/.gem/ruby/x86-mingw32/1.8/specifications/autotest-snarl-0.0.2.gemspec]: invalid date
format in specification: "2011-05-07 00:00:00.000000000Z"
C:/Users/Luis/Tools/ruby/ruby-1.8.7-p334-i386-mingw32/lib/ruby/site_ruby/1.8/rubygems/specification.rb:277:in `_resort!':
undefined method `name' for nil:NilClass (NoMethodError)

Not during installation but later in the process.

You can reproduce this using my simple gem here:

https://github.com/luislavena/autotest-snarl

I don't use anything that is not RubyGems and Rake to generate it (even use Gem::PackageTask)

Date: 2011-05-19 17:29
Sender: Alex Chaffee

Aha! That explains it. Thanks. I recently upgraded from 1.9.2-p0
to 1.9.2-p180 and when I did, I didn't pass in any options to
"rvm install". So it must not have found libyaml, and
therefore my 1.9.2 was using syck instead of psych, where my
1.8.7 was using psych and thus could read the time ok.

New workaround: (re)install Ruby like this:

rvm package install readline
sudo port install libyaml
rvm install 1.9.2 -C "--with-libyaml-dir=/opt/local
--with-readline-dir=$HOME/.rvm/usr"

See also http://stackoverflow.com/questions/3190737/error-install
ing-ruby-1-8-6-and-openssl-using-rvm-under-snow-leopard/3262368#3
262368 (where apparently I solved this problem a year ago and
then ignored my own instructions)

Date: 2011-05-19 00:35
Sender: Ryan Davis

It isn't the fractional seconds as everyone thinks... it is the
lack of a space before the "Z".

Psych has been "fixed" and made into a gem to address
this on the YAML side, and I've got a patch to normalize_yaml_input
to address things on the loading side.

Date: 2011-05-18 23:38
Sender: Alex Chaffee

Looks like this might fix it: specification:974

Change 

              if /\A(\d{4})-(\d{2})-(\d{2})\Z/ =~ date then
to

              if /\A(\d{4})-(\d{2})-(\d{2})\b/ =~ date then

(unit test notwithstanding, of course...)

Unfortunately it won't change it for earlier versions of Rubygems.
For that it'd be necessary to change the output... maybe a quick
hack like running gsub on the yaml output from builder.rb would
suffice.

Date: 2011-05-18 22:57
Sender: Alex Chaffee

Confirmed: Building the gem with 1.9.2p180 makes a metadata field
with a different date format than building the gem with 1.9.2p0.
And that new format is unreadable by older versions of Ruby.
I think it's that they added fractional seconds to the time,
and the poor old date parser breaks when it hits
".0000000".

It looks like Gem is just using "to_yaml" to turn the
spec into the metadata file (builder.rb:79), so this isn't something
that can be fixed with a simple strftime format tweak.

See also bug #29202

Date: 2011-05-18 22:25
Sender: Alex Chaffee

Verified on Ruby 1.9.2p180. This seems to have happened sometime
between 1.9.2-p0 and 1.9.2-p180, but I haven't yet done the regression
to confirm. I know 1.8.7 works OK.

To summarize: using MRI 1.9.2p180 to generate a gem results in
an invalid date format.

Workaround: use an older version or Ruby when *building* the
gem. And do "gem specification pkg/foo-1.2.3.gem | grep
date" to verify that your date is in the proper format before
pushing to gemcutter.