Home› Analyst Portal

How to keep/add timezone information to all views?

Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
in Analyst Portal
How do we keep/add the timezone information in the date/time columns of all of our views?

In direct contrast to the "remove timezone information from all views" thread and those linked from it, our organization is spread across 13 time zones and we frequently execute changes across daylight savings / summer / winter time changes.  This weekend, for example, we have several major changes that begin in Eastern Standard Time and end after Eastern Daylight Time begins.

The apparent change to the views in 7.4 generated a fair amount of excitement here (especially since it showed up right before a DST change in the US, with Europe following soon after).  It is equally frustrating to learn that this was not actually a feature and will disappear the first time the Reset button is clicked.

This is one of those cases where using moment.timezone.js to cast the given date/time in a specified timezone, but my question to everyone is more how should this be done than how can it be done.

Best Answer

Answers

  • Brett_MoffettBrett_Moffett Cireson PACE Super IT Monkey ✭✭✭✭✭
    IMHO, if you are trying to track deployment times or scheduled tasks across the globe and many time zones, I would operate in UTC for the actual change, then display that as the local time based on what TZ the user is in. (Which is how the portal operates now)

    If you wanted to, you could extend the class with Time Zone data for each time\date field so you could then display that, but I feel that analysts would then spend more time reverting that back to their local time zone to see what it affects them rather than caring what time it will be elsewhere during an outage.

    Example: I am an analyst here in Australia and I book a change to reboot the Orchestrator service between Midnight and 1am this Thursday.
    If an analyst picked up that change and looked at it would they want to know what time it is in Australia when the change occurs, or in their own time zone so they know that service wont be available? (2pm to 3pm Wednesday)

    if you had a defined number of time zones you supported (3 or 4 max) then I guess you could dynamically display on the portal (Using custom.js) the time zone in all your supported time zones on the screen so you could quickly tell end users when the service was going to be down....   but that would start to fill the screen pretty quick.

    Maybe an option like MS Outlook Calendar that allows you to choose one other time zone and have it show along side your system default one....   That could be a custom solution that I see could be useful.

    Maybe raise this as a feature request and if enough people also require it they can vote it up the list for the Dev team to evaluate.

    Good luck
  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    This misses the point a bit.  Storing the information in UTC is absolutely the right approach, and I am not suggesting otherwise.

    I am suggesting two other things:
    • If I am sitting in the Eastern US time zone, speaking with someone in Australia (let's say Sydney, so 14 hours ahead in AEST, I believe) about a change occurring in Sydney, is it best for me to see the time converted to EDT or to AEST?
    • If the above is not possible, would it not be helpful for me to see "EDT" next to the time and for my counterpart to see AEST next to the time, so that we do not argue whether the ticket should be set to 01:00 or 15:00 (as often happens, despite my communications about how time is handled in the portal)?
    I had raised this FR a while back to help with entry of times in other time zones (separate but related), but let's say it has not broken any popularity records.  I suppose this is not a concern for others and we may have to go our own way.  But I at least want to ensure that the use case is understood, in case there is an opportunity to build in some support in a later release.
Sign In or Register to comment.