http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5601 Summary: SIP Due dates miscalculated via DateTime Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: SIP2 AssignedTo: colin.campbell@ptfs-europe.com ReportedBy: ohiocore@gmail.com QAContact: koha-bugs@lists.koha-community.org Estimated Hours: 0.0 SIP checked out items report incorrect due date of 1 day earlier than actual due date. Koha data internally and staff interface both show correct date, so the error is only in SIP's "view" of the date. mysql> select itemnumber,barcode,onloan from items where barcode="33518003139989" or barcode="33518003273994"; +------------+----------------+------------+ | itemnumber | barcode | onloan | +------------+----------------+------------+ | 115532 | 33518003139989 | 2011-01-23 | | 127096 | 33518003273994 | 2011-01-23 | +------------+----------------+------------+ Staff interface shows, for example: "Checked out to 23518000442008 : due 01/23/2011". But when we pull it using SIP telnet login via an Item Information (17) request: 1720110103 115501AOLGPL|AB33518003139989| 1804020120110103 115559AB33518003139989|AJDon't sleep, there are snakes :|AQLGPL|BGLGPL|AH20110122 160000| 1720110103 115501AOLGPL|AB33518003273994| 1804020120110103 115655AB33518003273994|AJThe elegance of the hedgehog|AQLGPL|BGLGPL|AH20110122 160000| So that shows the date due stamp (AH) is consistently 8 hours early. The use of the DateTime module has introduced this logical error. This is exactly why *not* to use one-off new Date dependencies and string hacking in leaf code, if there is any way to avoid it. Specifically, the DateTime constructor does NOT default to local timezone, or in fact to ANY timezone, when invoked with the current arguments. You can demonstrate this w/ the following test: $ date Mon Jan 3 14:47:30 PST 2011 $ perl -e 'use DateTime; my $x=DateTime->now(); my $y=DateTime->new(year=>2011,month=>1,day=>3); print $x, " ", $x->time_zone_long_name(), " ", $x->epoch, "\n", $y, " ", $y->time_zone_long_name(), " ", $y->epoch, "\n"; ' 2011-01-03T22:47:33 UTC 1294094853 2011-01-03T00:00:00 floating 1294012800 So the timezone of the objects that we are getting is "floating". See: http://search.cpan.org/~drolsky/DateTime-0.66/lib/DateTime.pm#Floating_DateT... where we are advised: "If you are planning to use any objects with a real time zone, it is strongly recommended that you do not mix these with floating datetimes." All of our objects have real timezones, namely the local $ENV{TZ} one. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.