Locked
Discussion interactions are currently paused.
Timezone per user account
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.
Andy_Domeier
Posted 11 years ago·Last reply 8 years ago
29 comments
Forrest_Evans_-
·8 years agoFor everyone following this thread, User Based Timezones was released with version 108. You can read more about it here:
https://www.logicmonitor.com/release-notes/v-108-release-notes/
~Forrest
Thomas
·8 years agoGreat news! @Mosh is exactly right, we really just need the presentation layer (in the graphs etc) to have the times converted to a Time Zone set in the user profile. This would be a huge help! Looking forward to having this in the next release!
Mosh
·8 years agoGreat to hear @Ali Holmes!
Ali_Holmes
·8 years ago@mnagel this is in preparation for the change. Full functionality will be available in the next few releases - keep an eye on release notes for that announcement :)/emoticons/smile@2x.png 2x" title=":)" width="20">
mnagel
·8 years ago@Ali HolmesI saw a timezone field added to the user object in the v104 update, but nothing in the profile editor. Is that just preparation for this change, or can this be managed via the API and work now?
Mosh
·8 years agoHi @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.
Eric_Feldhusen
·8 years agoAli,
Thank you for your post and I will follow up with a direct email to you.
Eric Feldhusen
Ali_Holmes
·8 years agoHi 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
Lawrence_Brandt
·8 years agoI 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
Auriane
·8 years agoHello, has this item been scheduled for implementation yet? Thanks
mnagel
·8 years ago@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
Eric_Feldhusen
·8 years agoWe'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
Mosh
·8 years agoWe'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.
3nin6
·8 years ago+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:
/topic/1383-time-zone-based-on-group-of-devices/Lawrence_Brandt
·8 years agoThis request is 138 weeks, almost 1,000 days old! We just starting using this product, is this how long things usually take for a change?
Bruce_Berger
·8 years agoWhat 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.
VBen
·9 years agoHi,
Monitoring an international infrastructure myself, we really need this feature, come on react to this, it's time to implement that feature !
Rahamath
·9 years agoWe also have this requirement. Is there any update on the requests.
Eugene_C
·9 years agoIt's really necessary feature.
mnagel
·9 years agoAlso 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.
lostinfuture
·9 years agoHello 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!
David
·9 years agoHi LogicMonitor,
We are also in a similar situation. Has there been any movement on getting this slotted into the dev cycle?
Mosh
·9 years agoDear 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?
PatrickATL
·9 years ago+1 for this
mnagel
·9 years agoWe 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
Eric
·9 years agoThis 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?
Narr_Sunkara
·10 years agoHi 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
Max_K_
·10 years agoGood 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
Nick_Stenroos-D
·11 years agoWe are going to need this as well.