Comment 7 for bug 978287

Confirmed in 2.2 under slightly different circumstances, but I believe it's the same issue:

Currently in US/Eastern the offset from UTC is -0400. Circulations with a due_date having a -0500 offset (roughly, anything due after the DST "fall back" date of Nov 4) are affected when backdated to an -0400 timestamp.

Example (no problem):

Given a circulation with due_time 2012-11-02 23:59:59-04 checked in today with a backdate value of today, we'll end up with a checkin_time of 2012-11-01 23:59:59-04 and a checkin_scan_time of 2012-11-01 16:22:57.559085-04

All is well here, and all timestamps have an -0400 offset.

Here's a problem example:

Circ with a due_time after Nov 4 DST "fall back" date: 2012-11-14 23:59:59-05 checked in today with a backdate value of today, we have a checkin_time of 2012-11-02 00:59:59-04 and a checkin_scan_time of 2012-11-01 16:26:20.8181-04

The circulation shows a checkin_time with a date one day after the backdate date supplied. Since these are being backdated to "today" (unusual, yes), this means that the circulations were returned "tomorrow". Since they're not due yet, there's no extra day of fines, but the future checkin date does stick out.

The issue is how checkin_handle_backdate in OpenILS::Application::Circ::Circulate is "taking the due-time from the original due-date".

Since we're pushing all due times to 23:59:59 when the circulation is day-granular, and we're already not providing a means for a backdate of (for example) an hourly checkout, the simplest fix for this issue while not losing any functionality might be to always backdate to 23:59:59. This could then be re-addressed if support for non-day-granular backdating is added.