[Koha-bugs] [Bug 5601] New: SIP Due dates miscalculated via DateTime

[bugzilla-daemon at bugs.koha-community.org]

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 at ptfs-europe.com
        ReportedBy: ohiocore at gmail.com
         QAContact: koha-bugs at 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_DateTimes

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.