Patron expiration date & iPads

Bug #1840950 reported by Terran McCanna
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Evergreen
Won't Fix
Medium
Unassigned

Bug Description

Evergreen 3.2.3

We are receiving reports from the field that staff using iPads or iPad Pros are getting an empty expiration date field when they retrieve patron accounts (screenshot attached).

We were able to confirm that this is happening on a testbox running 3.2.3 master as well.

Revision history for this message
Terran McCanna (tmccanna) wrote :
Revision history for this message
Chris Sharp (chrissharp123) wrote :

I can confirm this is happening. One of our library systems purchased iPads based on the idea that the web client works well on tablets and this issue is creating trouble for staff offsite.

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
tags: added: webstaffclient
Revision history for this message
Chris Sharp (chrissharp123) wrote :

I have confirmed that this issue is present in Safari on MacOS, which has far more accessible web development tools built in. More soon.

tags: added: ios
tags: added: usability
Revision history for this message
Chris Sharp (chrissharp123) wrote :

The error I see in the console on Safari is:

Timepicker directive: "ng-model" value must be a Date object, a number of milliseconds since 01.01.1970 or a string representing an RFC2822 or ISO 8601 date.

Revision history for this message
Chris Sharp (chrissharp123) wrote :
Revision history for this message
Dan Wells (dbw2) wrote :

A few things worth noting:

1) The error message used to show up in two places in the angular-ui Bootstrap code, and now it is in just one. Not especially helpful, but this at least explains why we are seeing this error despite finding evidence it was removed several years ago.

2) The crux of this problem comes down to the fact that Safari is more picky about parsing ISO8601 date strings. From what I can tell, the standard says that colons in timezone markings are optional, but in Safari-land, they are required. The following line works in Chrome/Firefox, dies in Safari:

new Date('2020-06-05T01:00:00-0400');

*However*, the following (add a colon) works in all:

new Date('2020-06-05T01:00:00-04:00');

I am not exactly sure where the four-digit, no-colon timezone is coming from in this case, I didn't dig quite that far. It appears it comes straight from the OSRF translator response, so it looks to originate server-side. The DB for me is showing 2-digit timezones in psql, so suspicion falls to the Perl code. There are at least four acceptable ways to format the timezone, and we appear to use a variety throughout EG.

Finally, oddly enough, the same date format does not die when displaying the patron create date, so we must be handling things somewhat differently there.

Dan

Revision history for this message
Dan Wells (dbw2) wrote :

For reference, it appears that Safari is actually following the latest ECMAScript spec regarding the colon:

http://www.ecma-international.org/ecma-262/10.0/index.html#sec-date-time-string-format

ECMA describes the official string format as "a simplification of the ISO 8601 calendar date extended format".

Revision history for this message
Terran McCanna (tmccanna) wrote :
tags: added: pullrequest
Changed in evergreen:
assignee: nobody → Rogan Hamby (rogan-hamby)
Revision history for this message
Rogan Hamby (rogan-hamby) wrote :

worked for me, sign off at user/rogan/lp1840950_mac_patron_expiration_date

Changed in evergreen:
assignee: Rogan Hamby (rogan-hamby) → nobody
tags: added: signedoff
Galen Charlton (gmc)
Changed in evergreen:
assignee: nobody → Galen Charlton (gmc)
Changed in evergreen:
milestone: none → 3.6.1
Changed in evergreen:
milestone: 3.6.1 → 3.6.2
Changed in evergreen:
milestone: 3.6.2 → 3.6.3
tags: removed: webstaffclient
Changed in evergreen:
milestone: 3.6.3 → 3.6.4
Changed in evergreen:
milestone: 3.6.4 → 3.7.2
Changed in evergreen:
milestone: 3.7.2 → 3.7.3
no longer affects: evergreen/3.6
Changed in evergreen:
milestone: 3.7.3 → none
Changed in evergreen:
milestone: none → 3.9.1
Changed in evergreen:
milestone: 3.9.1 → 3.9.2
no longer affects: evergreen/3.4
no longer affects: evergreen/3.5
Revision history for this message
Jason Boyer (jboyer) wrote :

Is this still a valid issue? I was looking at a 3.10 system this weekend and the expiration date displayed as expected. Has Safari cured this for us or can someone still trigger this bug on iOS 15 or 16 or macOS 12 or 13?

Revision history for this message
Rogan Hamby (rogan-hamby) wrote : Re: [Bug 1840950] Re: Patron expiration date & iPads

I have a memory of this being fixed for us a while back but not specifics
so I'm re-testing.

iPad running iPad OS 16.2 and an Evergreen 3.9.x system - all good

Mac with Safari version 16.3 and an Evergreen 3.9.x system - all good

On Mon, Feb 13, 2023 at 6:55 AM Jason Boyer <email address hidden>
wrote:

> Is this still a valid issue? I was looking at a 3.10 system this weekend
> and the expiration date displayed as expected. Has Safari cured this for
> us or can someone still trigger this bug on iOS 15 or 16 or macOS 12 or
> 13?
>
> --
> You received this bug notification because you are a member of Evergreen
> Bug Wranglers, which is subscribed to Evergreen.
> Matching subscriptions: evergreenbugs
> https://bugs.launchpad.net/bugs/1840950
>
> Title:
> Patron expiration date & iPads
>
> Status in Evergreen:
> Confirmed
>
> Bug description:
> Evergreen 3.2.3
>
> We are receiving reports from the field that staff using iPads or iPad
> Pros are getting an empty expiration date field when they retrieve
> patron accounts (screenshot attached).
>
> We were able to confirm that this is happening on a testbox running
> 3.2.3 master as well.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1840950/+subscriptions
>
>

Changed in evergreen:
milestone: 3.9.2 → none
Revision history for this message
Galen Charlton (gmc) wrote :

Looks like WebKit (the engine that Safari uses) relaxed the requirement back in 2020. Consequently, I'm marking this as wont-fix.

(Also noting that a consideration here is that if we ended up wanting to hew more closely to ECMAScript - though I question its decision to use a "simplification of ISO 8601" - doing that would call for more centralization of date/time parsing in the client rather than a one-shot change for just one field.

Revision history for this message
Galen Charlton (gmc) wrote :

Whoops, I meant to cite the WebKit bug where they changed the behavior: https://bugs.webkit.org/show_bug.cgi?id=170720

Changed in evergreen:
assignee: Galen Charlton (gmc) → nobody
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.