due dates rolled past midnight in local time zone
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
Evergreen: 2.2
Postgres: 9.1
When checking out items, any items with an interval > 1 day will be rolled to midnight server time. However, if a library is a time zone east of your server, the item will be due at 1AM the next day, thus patrons will see the wrong due date.
I've created a patch which adds a timezone org unit setting and actually sets the time zone correctly in the circulation perl code
HOWEVER, there is still another issue -- a database trigger still rolls the time to midnight server time.
Simply removing this trigger will alter the behaviour of the manual due-date selection widget. Currently this widget will roll the due dates to midnight for >= 1 day circ durations. Current users may rely on or expect this behaviour. Simply removing the database trigger will cause that widget to always literally use the exact time value specified.
I would suggest that the widget is not ideal UX in the first place and recommend that prior to removing the trigger we re-work the widget to have several options:
1) Select a specific due date
2) Select a specific due date /w time
3) Select a relative due date (ie: 5 days, 1 hour, etc)
For now, the first part of this fix is available here and it adds YAOUS for timezone. In order to have a list of timezones for the setting, this patch also creates a list of every time zone in a table called "config.timezone" populated from pg_timezone_names. These time zones also accomodate jurisdictions which don't participate in daylight savings time, for example America/
working/
Changed in evergreen: | |
status: | New → Confirmed |
As an alternative to throwing out the trigger, changing the create_due_date() function, and redoing the due date UI, could we just pull the new time zone info into the trigger instead? Use 'SET LOCAL TIME ZONE XYZ' (substitute a real TZ) in the trigger before we mangle the date, then it would get set to 11:59pm for the library doing the circ, and whatever that happens to be for the server.
We might need to consider in a few places what happens to the date when it comes back out, but if we already see the "wrong" due date now, then the code is already doing the time zone shift on output in at least one place.