Hi there,
I've been working on some time zone support for Evergreen to accomodate the
inclusion of Manitoba SPRUCE into the Sitka family, as well as our long
suffering libraries in B.C. but using Mountain Time, and the few sites who
don't use daylight savings.
The main issue with due dates, is that a database trigger pushes all
day-interval due dates to 23:59 in the server time. Unfortuately, the staff
client does convert this time when displayed, for example sites in Mountain
time see this as 00:59. This is very bad, as it's basically the next day, so
the due date is really not very accurate for them.
In order to circumvent this, I've removed the trigger and enhanced a block of
code around O:A:Circ:Circulate.pm +2172 which already contained an incomplete
time zone bit to actually be functional:
# get time zone from org setting, failing that use local (server time zone)
my $tz = $U->ou_ancestor_setting_value($self->circ_lib, 'global.timezone')
|| 'local';
# set the due date to 'now' in that time zone
my $due_date = DateTime->now(time_zone => $tz);
#if we're dealing with an interval that evenly divides into days, we want
to push it to 23:59 of the due day
#first we take the 'now' in the correct time zone and push it to 23:59
my $ddseconds = OpenSRF::Utils->interval_to_seconds($duration);
if($ddseconds % 86400 == 0){
$due_date = DateTime->new(
year => $due_date->year,
month => $due_date->month,
day => $due_date->day,
hour => 23,
minute => 59,
time_zone => $tz,
);
}
The timezone setting itself is a "link" type setting with a new fieldmapper
table that is basically just a copy of Postgres' internal time zone names
(pg_timezone_names -- although as a copy of that table, the idea being that the
list could be truncated based on local needs as it's very large)
So far it works great in non-production testing. But right now my current
problem with this approach is that it doesn't adjust manually set due dates --
those are not passed through this function (as they don't have a
$circ->interval), so it means that a multiday loan that is set manually in the
staff client, will not be pushed to 23:59.
There are numerous ways I could restore the previous functionality, however
I've been thinking about this, and the previous functionality of pushing any
multi-day loan to 23:59 is not intuitive and probably breaks some usability
concepts. If there is a manual due time selector, the user should expect it to
actually set the time, a user wouldn't normally expect it to be pushed to 23:59
if there is a time selector -- there's nothing telling the user when it's going
to be pushed to 23:59 so it's not intuitive and breaks the user's expectation.
It's a bit different than when the server calculates a due date interval from
7 days as there's no time directly associated with that interval.
My personal preference would be to enhance the staff client have a popup or
some way of selecting between just a "due date" with no time option, implicit
that the time will be pushed to 23:59, and then either a "due date + time"
option, or just a "time" option, presuming that the item would be due the same
day. Another important feature that may be worth adding here would be some way
of having a buch of presets, for example 1 hour, 3 hours, or 1 day, 3 days,
etc. I haven't done anything with this piece yet but I'd appreciate any
feedback or thoughts on how it should work.
Thanks
James Fournie
BC Libraries Cooperative
