DateTime - Revisit examples and minor guidance

[KennyAtHPE]

Keeping the original content of this issue for history and consideration, but posing the question "can we simplify and reduce content if we follow the use cases provided in this comment?"

---

Previous ticket #3494 Previous PR #3503

---

The following items have been omitted in the first version of the Date and Time guidance:

• Log file example (requires a real use case)
  • UTC time? Locale time? Local timezone converted to UTC offset?
• Run time example (requires a real use case)
• RFC 3339 formatting (might not be needed as it follows the specs for ISO 8601 formatting)

Design deliverable:

• [ ] Link to Figma file showing log file example
• [ ] Link to Figma file showing run time example

Developer deliverable:

• [ ] PR merged with log file and run time examples added

[SmWorkGitHub]

A couple of use cases for analytics can be seen in this InfoSight prototype. Not sure they're in scope for this iteration of the guidance. I'm sure they've come up in the GLCP dashboard projects, as well:

Data freshness: In Storage we usually put a "Last updated 15 min ago" text lable in the upper right corner of the container for the data table/chart/whatever. The answer to that question is very important to users. I'm not sure our old design is salient enough.

Selected time range: Time series charts, reports, dashboards often have a date/time picker on the toolbar with the exact date range selected shown underneath. It displays the value of a custom time range. It also answers questions about exactly what "1 day" means, e.g., when there's a lag so that it's last 24h starting at the top of the last hour.

The Alignment section doesn't address these two use cases. Otherwise, the guidance looks pretty good.

[halocline]

We (@ecircenis , @SeamusLeonardHPE , @CillianHPE , @taysea ) discussed seeing if we could simplify the date-time guidance to make it more straight-forward and digestible.

Guidance @ecircenis is supplying to GLCP:

"Showing dates/times in UTC is not useful to users and forces them to have to do mental calculations to convert timestamps into a frame of reference that is comfortable for the user. It is good that your timestamps are all stored internally in UTC. But, when presenting times to the user, the default should always be to present them in a localized format, where the locale is defined by (in order):

• A user-specified preference
• In the absence of a user-preference, the browser's locale.
• In the absence of a valid/supported browser locale, en-US.

The image I'm sharing shows the date/time formats we are trying to standardize on for GreenLake. Exceptions include:

• If crafting a sentence that includes a date stamp, use the full month name. dateStyle:'long'
• If you need to add relative information, append this to an existing supported time format as in: Mar 5, 2025 (in 3 days)
• If sending an email from the platform and not knowing what timezone the recipient may be in, use UTC.
• Date on chart axis - the charting package is typically responsible for formatting in a way that fits and for localization."

cc: @julauxen