Both build of rubygem-rspec-core 2.6.0 and 2.6.2 on Fedora koji 
used rubygems 1.7.2, and only 2.6.2 build result is broken.

rspec-core 2.6.2 already has broken date format in metadata.gz.
Once switching back to rubygem-rspec-core (because I think we won't backport
rubygem size "workaround" to F-14 rubygems 1.3.7, while updates-candidate
rubygem-rspec-core 2.6.2 on F-14 is also broken).

BTW I have not checked rubygems 1.8.x yet

Fixed in both rubygem-rspec-core and rubygems side

rubygems-1.7.2-2.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/rubygems-1.7.2-2.fc15

(In reply to comment #1)
> Both build of rubygem-rspec-core 2.6.0 and 2.6.2 on Fedora koji 
> used rubygems 1.7.2, and only 2.6.2 build result is broken.
> 
> rspec-core 2.6.2 already has broken date format in metadata.gz.
> Once switching back to rubygem-rspec-core (because I think we won't backport
> rubygem size "workaround" to F-14 rubygems 1.3.7, while updates-candidate
> rubygem-rspec-core 2.6.2 on F-14 is also broken).

It seems that the upstream gem was prepared using R 1.9.2 while the previous versions were not (or at least they were not prepared using Psych). I am afraid that we will see more problems of this kind in the future.



(In reply to comment #2)
> BTW I have not checked rubygems 1.8.x yet

I am perfectly fine with rubygems 1.8 for rawhide (just announce it on Ruby-SIG since this updates tends to break things), but IMO we should stay with 1.7.2 for F15 anyway.

Well, now I've checked rubygems 1.3.7 (on F-14), and rubygems 1.3.7 actually seem to read "broken" rspec-core 2.6.2 gemspec file.
---------------------------------------------------------
--- rubygems-1.3.7-2.fc14.src/rubygems-1.3.7/lib/rubygems/specification.rb      2010-04-22 13:43:03.000000000 +0900
+++ rubygems-1.7.2-2.fc16.src/rubygems-1.7.2/lib/rubygems/specification.rb      2011-04-06 05:55:10.000000000 +0900
---------------------------------------------------------
@@ -1272,117 +1167,210 @@
....<skip>.....
+  def date= date
     # We want to end up with a Time object with one-day resolution.
     # This is the cleanest, most-readable, faster-than-using-Date
     # way to do it.
-    case date
-    when String then
-      @date = if /\A(\d{4})-(\d{2})-(\d{2})\Z/ =~ date then
-                Time.local($1.to_i, $2.to_i, $3.to_i)
+    @date = case date
+            when String then
+              if /\A(\d{4})-(\d{2})-(\d{2})\Z/ =~ date then
+                Time.utc($1.to_i, $2.to_i, $3.to_i)
               else
-                require 'time'
-                Time.parse date
+                raise(Gem::InvalidSpecificationException,
+                      "invalid date format in specification: #{date.inspect}")
               end
-------------------------------------------------------------
So rubygem 1.3.7 uses Time.parse() and on F-14:
-------------------------------------------------------------
$ irb
irb(main):001:0> require "time"
=> true
irb(main):002:0> Time.parse("2011-05-21 00:00:00.000000000Z")
=> Sat May 21 00:00:00 UTC 2011
irb(main):003:0> 
-------------------------------------------------------------
parsing "wrong" time format does not fail 
(and it seems that parsing really "wrong" time string doesn't seem to fail either).
-------------------------------------------------------------
irb(main):003:0> Time.parse("foo")
=> Mon May 30 12:47:51 +0900 2011
-------------------------------------------------------------

So it seems that backporting fix on rubygems 1.7.2 to F-14 1.3.7 seems unnecessary

(note that I've already modified both rubygems and rubygem-rspec-core on F15 and rawhide, although I've not tried rubygems 1.8.4(currently) yet)

I will upgrade rubygems to 1.8.5 on rawhide once I get back to home today (source already imported into Fedora git repository, however build queue was cancelled because of koji server down: I will resubmit it)

rubygems-1.7.2-2.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.