What does this MR do?
Enable user setting for absolute dates
A long while ago we have created a feature flag
:user_time_settings which introduced one feature flag for three
- User setting for relative/absolute date formatting
- User setting for 24-hour format
- User setting for setting time zones on profiles
This commit untangles this a little bit and allows users to change from our default (relative date formatting) to absolute date formatting with the help of the Intl.DateTimeFormat API.
From a frontend perspective we luckily do (almost all)
operations for formatting relative dates in one utility file, so it is
really easy to hook into that and render absolute dates.
The only thing we need to do from a backend perspective: We need to
expose the already existing user setting
window.gon so that the frontend can use it.
So what did we do in this commit:
- Update Preferences page pulling
Time preferencesinto a new section outside of the feature flag and expose the
- Keep the
time_format_in_24huser setting behind the feature flag, because we are not using it right now. And to be honest, we can likely remove it (see further down for reasoning)
- Expose the user setting on Gon as
- Based on
gon.time_display_relativewe either render relative or absolute dates.
- The date format chosen looks like
May 18, 2021, 3:57 PMfor the default English settings. (not showing time zones or seconds)
What didn't we do in this commit:
- We could and should teach
createDateTimeFormatto respect the browser settings and fall back on the language settings. If we really want to give the user control, we could introduce another user setting to define their wanted locale, but this is what browser settings are for. If e.g. a user has
en_GBas their browser locale dates would render in 24h format automatically, rendering the
- We should adjust our current
formatDateAPI (still used for the tooltip and showing time zone and seconds) to utilize
Intl.DateTimeFormatas well. This would unify the implementation, make it more consistent and likely faster, smaller. This would also solve loads of issues around weirdly formatted dates
- We didn't adjust the
timeForfunction which is used for due dates and such.
- We didn't fix the one direct import of timeago.
- Implement a instance-wide setting like the Start of the Week.
The only real risks here are:
- Somewhere where we really need relative dates might show absolute dates. (I cannot contrive an example)
- Somewhere layout breaks with absolute dates.
I don't think these risks compare to the benefit that this brings to users that wanted (or needed this) for a long time. If something really breaks, the user could always disable it again.
Screenshots or Screencasts (strongly suggested)
Does this MR meet the acceptance criteria?
I have included changelog trailers, or none are needed. (Does this MR need a changelog?)
I have added/updated documentation, or it's not needed. (Is documentation required?)
I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?)
I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?)
I have self-reviewed this MR per code review guidelines.
This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines)
I have followed the style guides.
This change is backwards compatible across updates, or this does not apply.
Availability and Testing
I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.)
I have tested this MR in all supported browsers, or it's not needed.
I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.
Does this MR contain changes to processing or storing of credentials or tokens, authorization and authentication methods or other items described in the security review guidelines? If not, then delete this Security section.
Label as security and @ mention
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
Security reports checked/validated by a reviewer from the AppSec team