Enable user setting for absolute dates
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
settings:
- 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) timeago.js
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 time_display_relative
in
window.gon
so that the frontend can use it.
So what did we do in this commit:
- Update Preferences page pulling
Time preferences
into a new section outside of the feature flag and expose thetime_display_relative
user setting. - Keep the
time_format_in_24h
user 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
gon.time_display_relative
- Based on
gon.time_display_relative
we either render relative or absolute dates. - The date format chosen looks like
May 18, 2021, 3:57 PM
for the default English settings. (not showing time zones or seconds)
What didn't we do in this commit:
- We could and should teach
createDateTimeFormat
to 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 hasen_GB
as their browser locale dates would render in 24h format automatically, rendering thetime_format_in_24h
setting obsolete. - We should adjust our current
formatDate
API (still used for the tooltip and showing time zone and seconds) to utilizeIntl.DateTimeFormat
as 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
timeFor
function 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)
What | Relative | Absolute |
---|---|---|
Settings | ||
Projects Dashboard | ||
Issues list | ||
Issue detail |
Does this MR meet the acceptance criteria?
Conformity
-
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.
Security
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 @gitlab-com/gl-security/appsec
-
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