Re: [OPEN-ILS-DEV] Solidifying / Simplifying Angular date/time display
On 2019-08-23 7:52 a.m., Bill Erickson wrote: 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/, which is an ambiguous format in Canada (DD/MM/ 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 -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. That's unfortunate. That doesn't negatively impact user experience in other ways? Overly locked-down workstations can be an annoyance, but the web client has only really required the ability to allow pop-ups (and optionally install Hatch) and to clear cache/local data if things stop working. As a rule we should try to avoid special requirements for browser configuration. I am of two minds. A de facto switch to US-style dates would be experienced by our libraries as a regression, and changing the browser locale would likely be a headache for some. But it's also not the end of the world. I don't want to simply kill the proposal if the community sees substantial benefits to it. It would be good to hear from others, especially non-American/non-en-US Evergreen users. Jeff
Re: [OPEN-ILS-DEV] Solidifying / Simplifying Angular date/time display
Hi Jeff, Comments inline... On Thu, Aug 22, 2019 at 8:37 PM Jeff Davis wrote: > 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? > Yes, we can make the proposed date display formatter use the selected locale, overriding the browser locale. > > 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/, which is an ambiguous > format in Canada (DD/MM/ 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 -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. > That's unfortunate. That doesn't negatively impact user experience in other ways? > > 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. > Well, that's the rub. The format for native date / time inputs is dictated by the browser, based on the browser locale. If overriding input formats is required, that essentially puts bug #1840782 to bed. We still have the option of using the proposed date formatter for display strings, but date / time inputs would require ng-bootstrap. I'm not sure if we'd still require MomentJS for date parsing, I need to review the code for #1834662. > > Aside from that, your assumptions and proposals look good to me. > Thanks for the feedback, Jeff. -b
Re: [OPEN-ILS-DEV] Solidifying / Simplifying Angular date/time display
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/, which is an ambiguous format in Canada (DD/MM/ 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 -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 (-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 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
[OPEN-ILS-DEV] Solidifying / Simplifying Angular date/time display
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 (-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 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
