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
