[OPEN-ILS-DEV] Solidifying / Simplifying Angular date/time display
Bill Erickson
berickxx at gmail.com
Fri Aug 23 10:52:28 EDT 2019
Hi Jeff,
Comments inline...
On Thu, Aug 22, 2019 at 8:37 PM Jeff Davis <jeff.davis at bc.libraries.coop>
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/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.
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20190823/a7d11cb7/attachment-0001.html>
More information about the Open-ils-dev
mailing list