Patron expiration date & iPads

[Terran McCanna]

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.

[Chris Sharp (chrissharp123)]

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.

[Chris Sharp (chrissharp123)]

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

[Chris Sharp (chrissharp123)]

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.

[Chris Sharp (chrissharp123)]

IRC discussion: http://irc.evergreen-ils.org/evergreen/2019-11-25#i_428095

[Dan Wells (dbw2)]

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

[Dan Wells (dbw2)]

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".

[Terran McCanna (tmccanna)]

My proposed fix is at:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mccanna/lp1840950_mac_patron_expiration_date

(Completed with help from the New Developers Group!)

[Rogan Hamby (rogan-hamby)]

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

[Jason Boyer (jboyer)]

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?

[Rogan Hamby (rogan-hamby)]

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
>
>

[Galen Charlton (gmc)]

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.

[Galen Charlton (gmc)]

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