[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