Andy Domeier

Timezone per user account

Recommended Posts

We are a global company with resources in Minnesota, New Jersey, Australia, Ukraine, and India all using the Logic Monitor tool set. It would be incredibly useful to be able to set the timezone at a user level instead of only at the company level.

  • Like 1
  • Upvote 6

Share this post


Link to post
Share on other sites

 

On 6.4.2016 at 6:58 PM, Annie Dunham said:

Hi Bruce - This got sidelined (due to a number of reasons) but is on Dev's plate for re-evaluation this sprint.  I'll update once we have an official release date, but promise it has not been forgotten.

 

Good to hear "promise it has not been forgotten" but more than one year passed since it has been requested!

It is arduous to recon the time difference every time we set a downtime or communicate with our branch offices around the globe.

thanks,

Max

  • Upvote 1

Share this post


Link to post
Share on other sites

Hi Annie, As a work around, can we change the current GMT setting to EST setting for us ? We have most of our services in EST and would be really helpful before the user level time changes are addressed.

Thanks

Narr

Share this post


Link to post
Share on other sites

This is a critical feature to be able to use your tool at a company with a global footprint like ours.  What is the right path for your customers to follow to be able to make this a priority in your product roadmap?

  • Upvote 1

Share this post


Link to post
Share on other sites

We need this as well.  Not only per-user timezone, but per-device timezone (inferred from location property would be a bonus).  Many of our customers span multiple timezones.  Time-related settings like escalations should be tied to the device impacted as well.

Thanks,

Mark

 

Share this post


Link to post
Share on other sites

Dear LM, how in the age is this not a feature yet?  Had I been at my company when LM was evaluated I would have not picked the tool just on this one point.  It's a major issue for us as a global business with regional IT centers.

Surely the date times are stored as epochs, no?

Edited by Mosh
  • Upvote 2

Share this post


Link to post
Share on other sites

Hi LogicMonitor,

We are also in a similar situation. Has there been any movement on getting this slotted into the dev cycle?

Share this post


Link to post
Share on other sites

Hello LogicMonitor team,

Please add possibility to change timezone per user account, not for the whole portal. For us as a global company it is critical feature, cause we have offices and equipment worldwide so engineers can see events in local timezone. Right now we have timezone configured for California, and it is not convenient to track events from Moscow, for example. Thanks in advance!

  • Upvote 2

Share this post


Link to post
Share on other sites

Also seconded.  Again.  Please fix!

-Mosh- I wish it was only large global enterprise customers.  We are setup as an MSP and shockingly have clients in different timezones than ours.  It is only a bit embarrassing to explain to those not in US/Pacific why they cannot see their graphs and other data in their local time.

Edited by Mike Suding

Share this post


Link to post
Share on other sites

Hi,

Monitoring an international infrastructure myself, we really need this feature, come on react to this, it's time to implement that feature !

Share this post


Link to post
Share on other sites

What is the status on this critical feature request? We have started to deploy in Azure all over the world and calculating time differences is way past becoming critical. We expended too many man-hours chasing nothing because the SDT on our CET server was off by an hour because of the 1 week difference in Autumn time changes between EU and US.

  • Upvote 1

Share this post


Link to post
Share on other sites

+1

We too would like to see this. While being a global company and many of us operationally running in UTC for efficiency, many members find the issue of time zones cumbersome. It also poses issues with SDT's where a device or service may be in a zone observing summer/daylight time. Since our portal is set UTC we have to manually adjust our SDT's to account for this.

(opening a separate feature req for assigning time zones to devices and services, or SDT's, whichever is easier -- as this appears to be a bit of a segway from this thread) EDIT:

found this req:

 

Edited by 3nin6
found other feature req to upvote instead of opening a new one

Share this post


Link to post
Share on other sites

We've had incidents where people have set the wrong times for SDTs.  It does not look good when we can lay the root cause blame on LogicMonitor for an incident.

Share this post


Link to post
Share on other sites

We're a service provider that provide a managed service of LogicMonitor, so we have multiple customers within our single instance of LogicMonitor.   As we expand, we have customers with devices in multiple timezones and from our experience, as we looked at it, our best suggestion would be for a user specific time zone setting, so that per user, they'd get the default time zone setting, unless they set their unique user setting for be another time zone, like PST, whereas we're in CST and that's what our instance is set for. 

Then, all time/date presented would just be in their set time zone across the board, so that they're seeing the information related to their set time zone, whether it's in an alert, graphing, or in dashboard(s).

We've already had multiple customers ask about this, so I think it's a setting worth doing.

Eric Feldhusen

Share this post


Link to post
Share on other sites

@Eric FeldhusenWe have similar issues and even then, many of our clients have a national or international footprint.  Per-user timezone is the most basic change that could be made to be useful (and should be trivial IMO), but the longer-term solution still should allow for per-device timezones.  The latter is more tricky to get right in terms of SDT, graphs, etc., but still should be done.  As far as I have seen in all the threads related to this, even the easy fix is not ever going to happen.  As others have stated, it is pretty embarrassing to have to explain this to clients paying a lot of money for this solution.

Mark

 

Share this post


Link to post
Share on other sites

I believe LM replied in some other thread that because GMT is built into the database and all the views, that it would be a major undertaking to change it. Though, I don't want to change the DB, just a few views we use, so I'd expect there shouldn't be that much issue. But, as you've said, there's no LM feedback to this thread.

-L

Share this post


Link to post
Share on other sites

Hi all,

This has been prioritized again for 2018. To provide a little background:

Changing the way data is displayed in the UI is relatively easy, but once data is outside of LogicMonitor (i.e. alert messages, report content) it is no longer dynamic. To change content based on recipient is much more complex, and we don't have a good solution for this (yet). The last thing we want to do is create inconsistencies that further complicate the issue we're trying to solve, which is why this project was put on hold in the past. We know how important it is to support our customers with global resources, we just want to make sure we do it right.

With that in mind, and to ensure things go smoothly this time around, we are considering approaching this in phases: 

1. Ability to view data in the UI (dashboards, devices, alerts) in user-specific time zone. All configuration operations (scheduling SDT, escalation chains, report delivery, report content, etc) are still done in the account/global time zone (this would be explicitly indicated in the configuration window). Alert messages (i.e. ##START## token) also remain in the account/global time zone.

2a. Ability to configure events (SDT, escalation chains, collector upgrade, report delivery, etc) in user-specific time zone (or possibly user-specified time zone via time zone picker). Each configuration will record and display in the time zone it was set in.  

2b. Ability to configure report content (SLA period, time range, etc) in user-specific time zone (or user-specified). Resulting report will be the same regardless of recipient.

3. Ability to receive alert messages and reports in recipient's time zone. 

We're interested to hear your feedback in terms of these phases as we work through the requirements. What is your highest priority? What percentage of your problems are solved by phase 1 alone? What are your biggest concerns? If alert messages are in a different time zone than your portal data, how does this affect your workflow?

If you prefer, you can shoot me an email at ali.holmes@logicmonitor.com.

-Ali

Share this post


Link to post
Share on other sites

Hi @Ali Holmes

My priority is item 1 on your list.  We can live with administration, configuration and time stamps in alert messages being in UTC, but having local times in the presentation layer would address most of the complaints I receive from my users.

  • Upvote 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now