DateTime picker displays mm/dd/yyyy time

[partiallyordered]

The date is 9 August, 2021

At the risk of overstating, this is confusing for roughly 96% of the human population. Proposed alternatives (that probably still have problems, but are better):

YYYY-MM-DD e.g. 2021-08-09

• Sorts lexicographically
• Language agnostic
• YYYY is probably clear, but the order of MM and DD may still confuse some readers. E.g. 2021-08-09: is this August 9 or September 8?

YYYY-MMM-DD e.g. 2021-Aug-09

• Does not sort lexicographically
• Not language agnostic (but can likely be internationalised)
• Not confusing

Internationalised long date, e.g. for GB: 9 August, 2021

• Does not sort lexicographically
• Language agnostic (assuming internationalisation)
• Not confusing

[millerabel]

I agree, this form of date can be confusing. We should not force it on anyone.

The local settings (called “locale”) determine the user’s preference for short and long date formats and language. How flexible this is may be browser dependent, but localization of date, time, and language formats is supported on all OS plats.

We should not guess when presenting dates to a user, let them specify their preference using the platform configuration tools for this. We will need to reason about formats and language choices that apply in the context where there are a group of users rather as part of a personal access profile, but likely still use the platform settings for locale when choosing a “local” format.

However, in representing machine-to-machine messages, we have adopted the international ISO 8601 standard form. Always. It is still easily recognizable by humans and is unambiguous.

If the use case is for parameterizing a search or filter or some kind of system configuration choice, we should use an ISO 8601 form (short or long, depending on circumstance). It avoids ambiguity in a potentially high risk ops environment.

It’s never wrong to use ISO 8601 form in a report, screen, or query, but it may be situationally more appropriate to use a local form (configured by the platform).

— Miller

On Aug 9, 2021, at 6:29 AM, Matt Kingston @.***> wrote:



The date is 9 August, 2021

At the risk of overstating, this is confusing for roughly 96% of the human population. Proposed alternatives (that probably still have problems, but are better):

YYYY-MM-DD e.g. 2021-08-09

Sorts lexicographically Language agnostic YYYY is probably clear, but the order of MM and DD may still confuse some readers. E.g. 2021-08-09: is this August 9 or September 8? YYYY-MMM-DD e.g. 2021-Aug-09

Does not sort lexicographically Not language agnostic (but can likely be internationalised) Not confusing Internationalised long date, e.g. for GB: 9 August, 2021

Does not sort lexicographically Language agnostic (assuming internationalisation) Not confusing — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[partiallyordered]

Thanks @millerabel. I didn't write as much, but I did mean ISO8601 with my first "proposed alternative". Assuming I end up working on this it's likely that's what I'll adopt in the short term as I'm not familiar with js/browser localisation. I think localised dates are probably preferable, but certainly more work.

[millerabel]

Thanks Matt. Using ISO8601 internally and within messaging protocols is the highest priority and gives us flexibility for other layers of the code. And it makes sense to study the localization design as part of the business process assessment, and to understand best practices for js/browser localization, before we dive in there.

8601 is a suitable and unambiguous external format, in the absence of localized forms for time and date. We would still need to deal with timezone configuration so that internal dates and times are UTC, but displayed adjusted for timezone. That’s the slippery slope into full localization.

Appreciate you’re looking into this.

On Aug 16, 2021, at 3:03 AM, Matt Kingston @.***> wrote:

 Thanks @millerabel. I didn't write as much, but I did mean ISO8601 with my first "proposed alternative". Assuming I end up working on this it's likely that's what I'll adopt in the short term as I'm not familiar with js/browser localisation. I think localised dates are probably preferable, but certainly more work.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.