Duplicate

There are several ideas posted in this area which, definitely, indicates the importance of this issue. The most voted one here (please keep voting for it):

https://community.sdl.com/ideas/tridion-ideas/i/tridion-sites-ideas/display-modification-datetime-of-items-based-on-users-time-zone-in-cme

See note from SDL that the change will be applied to all date/time value, not only modification date for which idea was reported:

"Current approach to implement this idea is to switch CM on server side (database, server logic, TOM.NET and CoreService APIs) to use UTC times only. Content Manager Explorer and Experience Manager will convert all date/time values to user local timezone on the fly. This change will be applied to all date/time values exposed in API, such as modification date, scheduled publish date, times when publish stansaction changed its state (e.g. from Rendering to Transporting), when workflow activity was started etc."

personalized time zone

This is an enhancement request that below.
---------------------------------------------
the server time is UTC 0 but most of the regional editor uses not UTC 0
so we need to have personalized time zone settings for easier to use.

The best is to change the server time to the same as the editor's location.
when I log in to CME, server time is 4:40 AM but now 13:40 PM in Japan.
So we would like to adjust it to 13:40

no need to change all environment timezone.
if we can select specific timezone when we use scheduled publish, and Event.
---------------------------------------------

Note there are basically two options which would require testing and or product changes before rolling out to a customer :

1. Update Server Time Time zones and stamps come from multiple "servers" (CM, CME, Publisher, RDS etc) so we would need to make sure everything was in sync. Would the change be forward or backwards in time? I have no idea what happens if version X + 1 has a time stamp earlier than version X.

2. Product change This would be to convert Server Time transarently for the user under the hood to local time. From a product point of view, this has come up and it's probably not hard, per se. It'll come down to priority and making changes across code bases, backwards compatibility, changes, etc. Other considerations: Maintenance a server time zone setting sounds like something that'd be easy to overlook and possibly missed/forgotten. I'd recommend scripting or somehow including this in however we (re)create environment.

Dan Cui
Parents

  • This only makes sense as a user interface enhancement. Assuming users are based in more than one timezone, (or only one, but different to where the server is), all items in the queues must share the same system. What is needed is a setting in the user preferences for an offset. So you can say that you want server time + 2, or whatever. Then in your user interface, all times from the server get displayed accordingly.

Comment

  • This only makes sense as a user interface enhancement. Assuming users are based in more than one timezone, (or only one, but different to where the server is), all items in the queues must share the same system. What is needed is a setting in the user preferences for an offset. So you can say that you want server time + 2, or whatever. Then in your user interface, all times from the server get displayed accordingly.

Children
No Data