Bug #39952 for DBIx-Class-TimeStamp: Negative error in DBIC TS

Fri Oct 10 11:42:58 2008 toddr [...] cpanel.net - Ticket created

Subject:

Negative error in DBIC TS

Hi I get the following errors when trying to install DBIC TS in 64 bit Linux: prove -bvm t/07date.t t/07date.... 1..3 ok 1 - created timestamp ok 2 - update and create timestamp The 'nanosecond' parameter ("-1.84467440737095516e+28") to DateTime::new did not pass the 'cannot be negative' callback at /opt/perl588/site/lib/x86_64-linux-thread-multi-ld/DateTime.pm line 169 DateTime::new('undef', 'hour', 0, 'minute', 1, 'month', 1, 'second', 0, ...) called at /opt/perl588/site/lib/x86_64-linux- thread-multi-ld/DateTime.pm line 466 DateTime::from_epoch('undef', 'epoch', 60.3172959999999989) called at t/07date.t line 11 main::__ANON__('DateTime') called at /home/a_trnact/.cpan/build/DBIx-Class-TimeStamp-0.06- U1ywHV/blib/lib/DBIx/Class/TimeStamp.pm line 79 DBIx::Class::TimeStamp::get_timestamp ('DBIC::TestSchema::TestDate=HASH(0x1a0bad0)') called at /opt/perl588/site/lib/DBIx/Class/DynamicDefault.pm line 113 DBIx::Class::DynamicDefault::update ('DBIC::TestSchema::TestDate=HASH(0x1a0bad0)') called at t/07date.t line 30 # Looks like you planned 3 tests but only ran 2. # Looks like your test died just after 2. Dubious, test returned 255 (wstat 65280, 0xff00) Failed 1/3 subtests Test Summary Report ------------------- t/07date (Wstat: 65280 Tests: 2 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 3 tests but ran 2. Files=1, Tests=2, 1 wallclock secs ( 0.03 usr 0.01 sys + 0.31 cusr 0.04 csys = 0.39 CPU) Result: FAIL

Fri Oct 10 11:44:31 2008 toddr [...] cpanel.net - Correspondence added

From:

todd.e.rinaldo [...] jpmorgan.com

A Similar error is manifesting during test for: t/05datetime t/06timestamp t/07date

Fri Oct 10 11:53:14 2008 jshirley+cpan [...] gmail.com - Correspondence added

On Fri Oct 10 11:44:31 2008, todd_rinaldo wrote: Show quoted text

> A Similar error is manifesting during test for: > > t/05datetime > t/06timestamp > t/07date

That's a really odd error message. It seems that the DateTime->now call fails. What's the output of: perl -MDateTime -MData::Dump=dump -e 'dump DateTime->now' If that works, can you unpack the DBIx::Class::TimeStamp dir (cpan> look DBIx::Class::TimeStamp) and then run the following: perl -Ilib -MDBIx::Class::TimeStamp -MData::Dump=dump -e 'dump DBIx::Class::TimeStamp->get_timestamp;' Thanks, -J

Fri Oct 10 11:53:15 2008 The RT System itself - Status changed from 'new' to 'open'

Fri Oct 10 12:17:21 2008 toddr [...] cpanel.net - Correspondence added

From:

todd.e.rinaldo [...] jpmorgan.com

perl -MDateTime -MData::Dump=dump -e 'dump DateTime->now' bless({ formatter => undef, local_c => { day => 10, day_of_quarter => 10, day_of_week => 5, day_of_year => 284, hour => 16, minute => 16, month => 10, quarter => 4, second => 33, year => 2008, }, local_rd_days => 733325, local_rd_secs => 58593, locale => bless({ "default_date_format_length" => "medium", "default_time_format_length" => "medium", en_complete_name => "English United States", en_language => "English", en_territory => "United States", id => "en_US", native_complete_name => "English United States", native_language => "English", native_territory => "United States", }, "DateTime::Locale::en_US"), offset_modifier => 0, rd_nanosecs => 0, tz => bless({ name => "UTC" }, "DateTime::TimeZone::UTC"), utc_rd_days => 733325, utc_rd_secs => 58593, utc_year => 2009, }, "DateTime")

Fri Oct 10 12:19:08 2008 toddr [...] cpanel.net - Correspondence added

From:

todd.e.rinaldo [...] jpmorgan.com

$ perl -Ilib -MDBIx::Class::TimeStamp -MData::Dump=dump -e 'dump DBIx::Class::TimeStamp->get_timestamp;' bless({ formatter => undef, local_c => { day => 10, day_of_quarter => 10, day_of_week => 5, day_of_year => 284, hour => 16, minute => 18, month => 10, quarter => 4, second => 31, year => 2008, }, local_rd_days => 733325, local_rd_secs => 58711, locale => bless({ "default_date_format_length" => "medium", "default_time_format_length" => "medium", en_complete_name => "English United States", en_language => "English", en_territory => "United States", id => "en_US", native_complete_name => "English United States", native_language => "English", native_territory => "United States", }, "DateTime::Locale::en_US"), offset_modifier => 0, rd_nanosecs => 0, tz => bless({ name => "UTC" }, "DateTime::TimeZone::UTC"), utc_rd_days => 733325, utc_rd_secs => 58711, utc_year => 2009, }, "DateTime")

Fri Oct 10 12:23:28 2008 toddr [...] cpanel.net - Correspondence added

From:

todd.e.rinaldo [...] jpmorgan.com

a quick diff of these outputs shows only the following 3 fields as differing: minute => 18, minute => 16, second => 31, second => 33, local_rd_secs => 58711, local_rd_secs => 58593, utc_rd_secs => 58711, utc_rd_secs => 58593,

Tue Oct 14 12:42:58 2008 toddr [...] cpanel.net - Correspondence added

From:

todd.e.rinaldo [...] jpmorgan.com

Added a few diags. The exact line that is failing in 05datetime.t is: $row->update({ display_name => 'updating test record' });

Tue Oct 14 12:44:09 2008 toddr [...] cpanel.net - Correspondence added

From:

todd.e.rinaldo [...] jpmorgan.com

I don't know the internals here, but I had a conversation with MST earlier about the instabliity of using a TS for a primary key. Is this what is being done here? Could this be the source of the problem?