O3: Config to set a standard date/time convention throughout App?

Development
, ,
1

Problems

We have 2 time-display problems to address as we build 3.x: (if I ignore timezones :stuck_out_tongue: )

  1. We don’t yet have 1 clear standard for date and time display throughout 3.x. Though we have repeatedly agreed in design conversations that we want to follow ISO-8601, where today’s date/time could be written as “2022-01-26 23:56” (note the 24 hour time format). I see this as semi-urgent as we are already having bugs like O3-1027 where the time “7pm” is being misleadingly displayed as “07:00”.

  2. Organizations may need to configure that standard to match their country/region’s policies (e.g. some regions are strict on the YYYY-DD-MM format, for reasons I’ll never understand).

Proposal

  • Have ONE place in O3 config, where the Date/Time format is specified; default is ISO-8601 format
  • All 3.x Dates/Times apply that Date/Time format in the UI
  • Implementers can configure this ONE place to change the format (e.g. to YYYY-DD-MM, 7:00pm etc)

What do folks think of this?

Has anyone encountered a solid real-world use case where you really needed TWO different formats within ONE implementation?

cc @jdick @mksd @bistenes @dkigen @mseaton @mogoodrich @pmanko

1 Like
2

Visual examples of current inconsistency in 3.x app: (e.g. 24hr vs AM/PM;

image

image

image
image962×300 18.1 KB

And Carbon adds further possibility for differences…

It seems like Carbon Design’s default is the opposite of what we want - they default to MM-DD-YYYY and AM/PM time. Since our vision is for folks around the world to be building 3.x widgets with Carbon Design, this makes having a single place that sets the user’s app’s convention even more important/relevant IMHO.

image
image962×162 16.8 KB

3

There’s a related conversation from Slack and @bistenes has added some helpful functions to display dates in consistent formats, e.g., formatDate.

Rather than standardising on ISO-8601 (which we should standardise on for machine dates–it’s really a specification for machine exhange), I think the idea of adopting locale-aware date and time formatting makes sense.

1 Like
4

I wouldn’t try to come up with one date display format for all implementations, since date formatting varies by locale. I think the pattern we’ve used previously was for the application to decide the type of display needed – e.g., short date (month & day) vs. full date, date & time, short time, full time – and then use utilities to generate standard, locale-specific versions.

So, for example, a table widget wants to display a short date (month & day), so it uses the utility and whether that becomes “3-Feb”, “Feb 3”, “2/3”, or “3/2” for display is decided by the utility function, which would take locale and implementation configuration preferences into consideration, to ensure dates are standardized across the app for any implementation. The locale drives whether things are “month/day” vs. “day/month” and implementer configuration could let them decide if they favor “-” or “/” delimiters, names or numbers for months, etc.

But the fundamental approach is to ensure anything display date, time, or date & time in the application uses a shared utility function and that shared utility function and ensure consistency throughout the application.

1 Like