Bug 642985

Some additional notes:

Koji build failed for me for the first time I tried to build this package. This seems like Koji issue/Xen issue with time. I tested it on my two machines and it worked fine. I disabled these asserts in tests for now using patch. (Kernel bug reported here: #640608)

Loaded suite test_time_stack_item
Started
FFF.............
Finished in 0.026321 seconds.
  1) Failure:
test_compute_dst_adjustment_for_dst_to_dst(TestTimeStackItem) [test_time_stack_item.rb:100]:
precondition.
<false> is not true.
  2) Failure:
test_compute_dst_adjustment_for_dst_to_non_dst(TestTimeStackItem) [test_time_stack_item.rb:118]:
precondition.
<false> is not true.
  3) Failure:
test_compute_dst_adjustment_for_non_dst_to_dst(TestTimeStackItem) [test_time_stack_item.rb:128]:
precondition.
<false> is not true.
16 tests, 53 assertions, 3 failures, 0 errors

After that:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2534587

Well,

When I try on my F-14 machine:
[tasaka1@localhost ~]$ uname -a
Linux localhost.localdomain 2.6.35.6-43.fc14.i686 #1 SMP Wed Oct 13 21:36:03 UTC 2010 i686 i686 i386 GNU/Linux
[tasaka1@localhost ~]$ rpm -q ruby
ruby-1.8.7.302-1.fc14.i686

I see one more failure (I am not using Xen or so)
$ ruby -I../lib ./test_time_stack_item.rb 
Loaded suite ./test_time_stack_item
Started
FFF.F...........
Finished in 0.113762 seconds.

  1) Failure:
test_compute_dst_adjustment_for_dst_to_dst(TestTimeStackItem) [./test_time_stack_item.rb:100]:
precondition.
<false> is not true.

  2) Failure:
test_compute_dst_adjustment_for_dst_to_non_dst(TestTimeStackItem) [./test_time_stack_item.rb:118]:
precondition.
<false> is not true.

  3) Failure:
test_compute_dst_adjustment_for_non_dst_to_dst(TestTimeStackItem) [./test_time_stack_item.rb:128]:
precondition.
<false> is not true.

  4) Failure:
test_datetime_for_dst_to_non_dst(TestTimeStackItem) [./test_time_stack_item.rb:139]:
<#<Date: 4910229/2,0,2299161>> expected but was
<#<Date: 4910231/2,0,2299161>>.

I guess the first 3 test failures are because Japan does not use
DST at all (currently uses JST = UTC + 9 hour all year) so 
for example
$ ruby -e "require 'time' ; puts Time.now.dst?"
always shows "false" (on Japan). Note that the line 100
in test_time_stack_item.rb says:
---------------------------------------------------------
   100      assert Time.now.dst?, "precondition"
---------------------------------------------------------

4th test failure occurs on the line 139 in test_time_stack_item.rb:
   132    # Ensure DateTime's handle changing DST properly
   133    def test_datetime_for_dst_to_non_dst
   134      Timecop.freeze(DateTime.parse("2009-12-1 00:38:00 -0500"))
   135      t = DateTime.parse("2009-10-11 00:00:00 -0400")
   136      tsi = Timecop::TimeStackItem.new(:freeze, t)
   137      assert_date_times_equal t, tsi.datetime
   138      # verify Date also 'moves backward' an hour to change the day
   139      assert_equal Date.new(2009, 10, 10), tsi.date
   140    end
I have not investigated here yet, however I think the failure on
this also related to timezone issue.

So I am not sure if the test failures are really related to
bug 640608. It seems that you have to set TZ or DST setting or so to make
these tests pass (I guess simply disabling these tests is simpler).

By the way for bug 640608:

It seems that
$ ruby -e 'otime = Time.now ; sleep(1) ; ctime=Time.now ; puts ctime - otime'
will call system calls: gettimeofday -> select -> gettimeofday.

However it seems that select() sometimes sleeps less time than
requested:
http://lkml.org/lkml/2008/8/29/232
... which seems fixed in kernel 2.6.28. So RHEL5 host may suffer from
this issue? (and perl seems to be using nanosleep instead of select)

Created attachment 454912 [details]
Use nanosleep() instead of select() for ruby sleep()

If bug 640608 is related to select(), the attached patch may
worth trying.

Would you update this?

(In reply to comment #3)
> By the way for bug 640608:
> 
> It seems that
> $ ruby -e 'otime = Time.now ; sleep(1) ; ctime=Time.now ; puts ctime - otime'
> will call system calls: gettimeofday -> select -> gettimeofday.
> 
> However it seems that select() sometimes sleeps less time than
> requested:
> http://lkml.org/lkml/2008/8/29/232
> ... which seems fixed in kernel 2.6.28. So RHEL5 host may suffer from
> this issue? (and perl seems to be using nanosleep instead of select)

Well, I AFAIK this bug is related just for Xen guests. Bare metal installations of RHEL5 is not suffering with this. And it's issue in kernel as far as I discussed with some kernel engineers.

(In reply to comment #4)
> Created attachment 454912 [details]
> Use nanosleep() instead of select() for ruby sleep()
> 
> If bug 640608 is related to select(), the attached patch may
> worth trying.

Yes definitely, this patch looks OK for solving this issue. I'll give it a try today and send you the results.

+ Agree on disabling those tests (for now). All tests are now passed in Koji.

========================= -2 ===================
* Thu Nov 09 2010 Michal Fojtik <mfojtik> - 0.3.5-2
- Disabled test_time_stack_item test

Spec URL: http://mifo.sk/RPMS/rubygem-timecop.spec
SRPM URL: http://mifo.sk/RPMS/rubygem-timecop-0.3.5-2.fc14.src.rpm

Okay.

----------------------------------------------------------
  This package (rubygem-timecop) is APPROVED by mtasaka
----------------------------------------------------------

Thanks for the review!

New Package SCM Request
=======================
Package Name:      rubygem-timecop
Short Description: Provides a unified method to mock Time.now, Date.today in a single call
Owners:            mfojtik
Branches:          f13 f14

Git done (by process-git-requests).

rubygem-timecop-0.3.5-2.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/rubygem-timecop-0.3.5-2.fc13

rubygem-timecop-0.3.5-2.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/rubygem-timecop-0.3.5-2.fc14

rubygem-timecop-0.3.5-2.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update rubygem-timecop'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/rubygem-timecop-0.3.5-2.fc14

Closing.

rubygem-timecop-0.3.5-2.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

rubygem-timecop-0.3.5-2.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.