Consider migrating to <input type="date" /> for Angular date selectors

[Bill Erickson]

Evergreen 3.3

Originally discussed here:

http://libmail.georgialibraries.org/pipermail/open-ils-dev/2019-August/010803.html

There is a general consensus so far that using the native browser date input in favor of the ng-bootstrap equivalent is a worthy goal. There remain some questions about usability and accessibility.

I've created a branch that migrates <eg-date-select /> so it may be used for review and comparison.

If we move forward with this, a separate LP for input type="time" would probably be in order.

Branch en route.

[Bill Erickson (berick)]

Here's a branch:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1840782-date-time-native-widgets

From the commit: ---

Migrate <eg-date-select> implementation from ng-bootstrap to the browser-native <input type="date"/> element.

Create a DateUtil class to package some common date transforms, etc.

'DOB' handling in FormatService leverages the new DateUtil class for generating a local date from Y/M/D and does so any time a simple Y/M/D value is passed, instead of limiting to 'DOB' values.

Sandbox example expanded to demonstrate date clearing and improve layout.

[Bill Erickson (berick)]

One thing to consider with this approach is the display format of the date is determined by the locale settings of the browser. The format cannot be controlled via JavaScript.

My understanding of the existing library settings for date / time formats is that they exist primarily to do the same thing -- allow dates to be displayed in the user's locale. However, it's of course possible to configure a display format this is not the same as the browser's display format for the locale.

So the question arises, do we need to support date display formats that differ from the standard format for each locale? Presumably what the browser uses for each locale is what users in those locales would most expect, or at least easily be able to understand, but maybe I'm too optimistic.

Note this does not impact non-input date displays, like dates in grid cells.

[Bill Erickson (berick)]

There is concern about not being able to modify the date input format for sites whose browser locale does not match the user locale, e.g. the users are unable to modify the browser settings. So, this bug is on hold until browser date selectors allow you to modify the format or the issue is otherwise resolved.

[Jason Stephenson (jstephenson)]

Well, I disagree with waiting for a feature that I don't see happening (i.e. programmatic control of date formats in the input type="date" field). This should be controlled by he browser's locale and ideally everyone should be using settings appropriate for their locale.

I'd recommend doing this in the OPAC, too, but Safari on Mac OS (and possibly other Webkit browsers) don't yet support input type = date (cf. bug 1723651).