Curbside - Appointments being pushed to next day

Bug #1917396 reported by Josh Stompro
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Fix Released
Fix Released

Bug Description

EG 3.3 - with curbside module code installed.

Hello, this may just be a local issue since we applied the curbside changes to our 3.3 system.

We just went back to later hours in one of our branches today, from a 6pm close to a 9pm close.

I received a report at 6:51pm that staff could no longer schedule appointments for the current day. They would enter 3/1/2021 7:30pm as the appointment time, and after pressing save they would receive back an appointment for 3/2/2021 7:30pm.

My suspicion is that it is timezone/UTC time related. We are on CST which is -6 UTC, so after 6pm, the UTC date is the next day. (I'm horrible with time related math, so this all could be way off.) It seems like the date and time slot are sent to the back end separately. So I'm wondering if a UTC date is getting sent by accident?

When I set a breakpoint at the updateAppointment function, I see the following info for the appointment.

slot: "2021-03-02T02:55:38.649Z"
slot_date: Tue Mar 02 2021 20:55:38 GMT-0600 (Central Standard Time) {}
slot_time: "09:00:00"

I suspect that this line is moving the date to the next day.
(new Date(appt.slot_date)).toISOString().substring(0, 10);a=blob;f=Open-ILS/web/js/ui/default/staff/circ/curbside/directives/schedule_pickup.js;h=6d8ae65e0ac416ef3b7aeccc48485383fc120901;hb=refs/heads/user/mmorgan/lp1879983_signoff#l324

When I run a little mock up of the toISOString at and start the date with "Tue Mar 02 2021 20:55:38 GMT-0600 (Central Standard Time)" I'm getting a result of "2021-03-03T02:55:38.000Z" which if I just took the first 10 characters would give me the next days date.


Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

When I test this morning I cannot trigger the issue.

And the Mozilla docs for toISOString seem to confirm that the date is converted to UTC when that function is used.

I'm testing in Chrome 88.0.4324.182

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

I don't really get why javascript date doesn't have a direct way to show the local date in ISO format?

There seem to be various methods to do it. Is there a standard way to do this in Evergreen already?

Here are a couple that seem to be the simplest.

const event = new Date('Tue Mar 02 2021 20:55:38 GMT-0600 (Central Standard Time)');

//Use the fact that Sweden uses a format that is very close to ISO
//Do locale formats change over time? That may be the downside to this method.
console.log(event.toLocaleString('sv').replace(' ', 'T'));

//Shift the date by the timezone offset, so when it is converted to UTC it is actually the local time
//remove the Z postfix for completeness
var tzoffset = event.getTimezoneOffset() * 60000; //offset in milliseconds
var localISOTime = (new Date(event - tzoffset)).toISOString().slice(0, -1);
// => '2015-01-26T06:40:36.181'

//one line
var isoDateTime = new Date(event.getTime() - (event.getTimezoneOffset() * 60000)).toISOString();

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

Working branch at user/stompro/lp1917396_curbside_timezone_issues;a=shortlog;h=refs/heads/user/stompro/lp1917396_curbside_timezone_issues

This worked on a test system, going to try in production now also.

tags: added: circulation curbside pullrequest
Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

This has solved the problem for us in production for the past month.

Changed in evergreen:
assignee: nobody → Terran McCanna (tmccanna)
Changed in evergreen:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Terran McCanna (tmccanna) wrote :

I was able to recreate this problem by changing the closing time of the current day to an earlier time than the next day. Prior to the fix, the available time slots appeared for the following day rather than the current day, which allowed the staff or patron to select an invalid time slot.

I confirm that the patch corrects this problem and only shows the times for the current date in both the staff client and the OPAC view.

My signoff is at:;a=shortlog;h=refs/heads/user/mccanna/lp1917396_curbside_timezone_issues_signoff

tags: added: signedoff
Changed in evergreen:
assignee: Terran McCanna (tmccanna) → nobody
Revision history for this message
Galen Charlton (gmc) wrote :

Pushed to master, rel_3_7, and rel_3_6. Thanks, Josh and Terran!

Changed in evergreen:
milestone: none → 3.7.2
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers