[MGNLUI-2695] User can configure his timezone Created: 19/Feb/14  Updated: 08/Mar/21  Resolved: 28/May/16

Status: Closed
Project: Magnolia UI
Component/s: workbench
Affects Version/s: 5.4.4
Fix Version/s: 5.4.7

Type: Improvement Priority: Neutral
Reporter: Daniel Lipp Assignee: Roman Kovařík
Resolution: Fixed Votes: 0
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File My profile-Preferences 1.png     PNG File My profile-Profile 1.png     PNG File Screen Shot 2016-05-19 at 14.06.13.png     PNG File TZ in list 1.png     PNG File TZ in list 2-user chosen.png     PNG File TZ in list 3-server time.png    
Issue Links:
Relates
relates to MGNLUI-4014 Investigate into corner cases: Wrong ... Closed
relates to MAGNOLIA-6660 Add timezone property to User class Closed
causality
is causing MGNLUI-3915 Default value in control for empty da... Open
is causing MGNLUI-3923 Scheduled date in Pulse is not displa... Closed
is causing MGNLUI-3933 Deprecated ctor of DateFieldFactory d... Closed
dependency
duplicate
duplicates MGNLUI-4092 Make date time formats editable or li... Closed
relation
is related to MGNLUI-2694 Dates and times should be displayed i... Closed
is related to MAGNOLIA-7108 users timezone permission delta task ... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Release notes required:
Yes
Documentation update required:
Yes
Date of First Response:
Sprint: Kromeriz 46
Story Points: 3

 Description   

How dates and times are shown in a UI depend on the context they are shown in.

I suggest we follow this concept for handling timezones:

  • Dates and times are stored in a clearly defined timezone on the server. There's a fallback timezone, in case that timezone is not set.
  • In AdminCentral, an editor has the choice to see all dates and times in either the server time zone or in a time zone of his choice. He specifies his preferences in the user settings dialog (see below).
    • In all editorial or admin apps such as Pages, Categories, Security, the timezone used is the one set by the user.
    • In all development or technical apps such as JCR tools, whenever we show or dump raw data such as nodes in the JCR config tree, the timezone used is the one of the server.
  • On the actual website, the choice should be up to site developer/customer/partner. He should have the possibility and no obstacles, to show dates and times:
    • in the timezone as they are stored on the server
    • in a hard-coded timezone defined for the site (e.g. a car hiring company in central europe hard codes the timezone to CET).
    • in the timezone guessed from the location a visitor surfs from or derived from browser settings.

Wireframe for editing a user's profile

We need to add a preference setting to pick the timezone we want dates and times to appear in. While doing so, we also clean up the dialog and group all settings it offers.

The first tab offers fields to enter data about a user and her account.
The second tab allows a user to pick her preferences related to the language (used mostly by the UI, but could also be referenced elsewhere) and date and time. We'll add the timezone preferences to the latter.

To pick a timezone, the user has the option to:

  • pick the timezone as currently configured and set on the server. The server's timezone is shown.
  • specify a timezone of her choice.

The list of timezones should be comprehensive and include major cities. A minimum set could only offer relative settings (e.g. "GMT +1h", "GMT +2h" or "UST -5h"), although that's user friendly.

Wireframes for revealing timezone in lists

In the List and Tree view, I suggest we continue not showing any timezone independant of the user's preferences to avoid sacrifying space for repetitive, clear information. Instead, we can reveal timezone information in a tooltip, if a user hovers or tap on a date value.

No timezone information shown by default.
The user-chosen timezone string is revealed in a tooltip.
If the user has chosen to use the server timezone instead, we might want to show an additional label "[server time]" to clarify that. I'm not sure that's needed, though.


 Comments   
Comment by Daniel Lipp [ 19/Feb/14 ]

MGNLUI-2694 and MGNLUI-2695 are related to timezone difference between client and server

Comment by Roman Kovařík [ 16/May/16 ]

To be validated:

  • allow to choose server time?
  • allow to choose browser time?
Comment by Mikaël Geljić [ 19/May/16 ]

Does this have to be questioned again? Indeed, our last conclusions for arch. meeting involve some adjustments to the mockups here, with server time zone being invalid (cc weder).

In the end the logical options for the preferred time zone should be:

  • Always use the browser *offset*
    • We cannot resolve one time zone just from browser info
    • We may make this clear for the user via appropriate labeling and description
  • In this time zone (no change from the mockups)

Also, in tooltips, unless there is a preferred time zone, we cannot show "(CEST)", again we only have the offset, so the clearest option is to go for the UTC-based offset "(UTC±08:45)".

  • ... unless a system-wide reference / fallback time zone is configured, but that's an idea I just had, no consensus on that atm.
Comment by Roman Kovařík [ 19/May/16 ]

Does this have to be questioned again.

I just wanted to alert the UX about the changes. Thx for explaining.

Also, in tooltips, unless there is a preferred time zone, we cannot show "(CEST)", again we only have the offset, so the clearest option is to go for the UTC-based offset "(UTC±08:45)"

This is what TimeZone class shows if the ID doesn't exist:

Comment by Mikaël Geljić [ 19/May/16 ]

Okay so it's GMT vs. UTC , I personally find GMT more old-fashioned/less universal but I haven't made research on that; either is fine.

Generated at Mon Feb 12 08:59:14 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.