[OPEN-ILS-DEV] Solidifying / Simplifying Angular date/time display

[Jeff Davis]

Hi Bill,

Does the Evergreen web client locale override the browser locale?  That 
is, if your browser is set to en-US and you select fr-CA from the web 
client locale picker, is it possible for the native date selectors to 
use fr-CA?

I don't think it's safe to assume that browsers are set to the correct 
or desired locale.  In English-speaking Canada, I am guessing that some 
users will have their locale set to en-US rather than en-CA.  This would 
result in dates being displayed using MM/DD/YYYY, which is an ambiguous 
format in Canada (DD/MM/YYYY is also used here, so 01/02/2019 could be 
either Jan 2 or Feb 1).

At Sitka we avoid the ambiguity by using Evergreen's date format 
settings to enforce the use of YYYY-MM-DD.  We would want to be able to 
do that without requiring users to modify their browser or OS locale 
settings, since not all users will have control of those settings.

If we could use the Evergreen web client locale instead of the browser 
locale to determine the native date input format, we could avoid the 
problem by forcing the use of en-CA rather than en-US in EG.  Retaining 
the date format org settings would also work.  But I'm not sure if 
Evergreen can dictate the format for native date inputs.

Aside from that, your assumptions and proposals look good to me.

Jeff

On 2019-08-22 2:49 p.m., Bill Erickson wrote:
> Hi All,
> 
> This is an extension of my previous email "Native browser date / time 
> selectors in Angular".
> 
> Based on discussion from that thread, from bug #1834662, and me poking 
> around the JS Intl.DateTimeFormat API, I would like to propose a way to 
> streamline and simplify how we handle locale-friendly dates and times in 
> the Angular application.
> 
> Assumptions:
> 
> 1. We need to support timezone database names as listed in 
> https://en.wikipedia.org/wiki/List_of_tz_database_time_zones (e.g. Europe/Prague, America/Vancouver, 
> etc.) since this is the documented basis for "lib.timezone" library setting.
> 
> 2. It is reasonable to assume dates generated by the web browser (via 
> Intl.DateTimeFormat API) for a given locale are understandable by users 
> in said locale and that we don't need to allow users to specify custom 
> date formats.  (See examples below)
> 
> 3. Browsers will be configured to the user's desired locale.
> 
> 4. Short / numeric dates and times are sufficient to convey the needed 
> information to users.  In other words, for en-US, "10/24/2019" is as 
> good as (or better than) "Thursday, October 24 2019" (or similar 
> variations).
> 
> For example, here's a list numeric date+time strings generated the 
> Intl.DateTimeFormat for a variety of locales:
> 
> cs-CZ ==> 22. 8. 2019 16:45
> en-CA ==> 2019-08-22, 4:45 p.m.
> fi-FI ==> 22.8.2019 klo 16.45
> fr-CA ==> 2019-08-22 16 h 45
> hy-AM ==> 2019-8-22 16:45
> es-ES ==> 22/8/2019 16:45
> ru-RU ==> 22.08.2019, 16:45
> en-US ==> 8/22/2019, 4:45 PM
> 
> 5. We need exactly 3 date/time flavors: date only, time only, and date + 
> time.
> 
> 6. For time displays, we need hours and minutes, but not seconds.
> 
> Assuming the above, here's my proposal.
> 
> 1. Migrate to native browser date and time inputs.  With these, we get 
> exactly 1 type of value from each widget (YYYY-MM-DD, hh:mm:ss) so we 
> never have to parse locale-variant date strings.  (No MomentJS dependency)
> 
> 2. Avoid using Angular DatePipe.  It does not support the long-form 
> timezone names we use (https://github.com/angular/angular/issues/20225).
> 
> 3. Teach our FormatService to use Intl.DateTimeFormat when generating 
> date strings.  It will support options to produce date, time, or date + 
> time, using the 'short' formats noted above, plus optional timezone and 
> locale parameters.
> 
> 4. Remove the date / time format library settings once fully migrated to 
> Angular.  All that's needed is locale and time zone.
> 
> As is often the case, I write code before I write emails, so I've mostly 
> implemented everything I've discussed here -- minus an <eg-time-select/> 
> widget -- in the code for 
> https://bugs.launchpad.net/evergreen/+bug/1840782  It also includes a 
> sandbox date/time generator tool where you can pick locales and time 
> zones and see what it produces.
> 
> I can say with confidence what I'm describing works in Chrome and 
> Firefox, so the question boils down to whether the assumptions I've laid 
> out are reasonable.
> 
> Thoughts appreciated,
> 
> Thanks
> 
> -b
> 
> 
> 
>