-
-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: different monitor timezones from user timezone (#5201) #5212
base: master
Are you sure you want to change the base?
feat: different monitor timezones from user timezone (#5201) #5212
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I forgot to tell more specifically than @GogoFC how I want changes done in this case.
Sorry about that
To know what time server went down and up in the timezone where the servers is located at
Adding more options to the monitor (especially if they are as specific as this one) are not something I want. The UI is already way too complicated and specific for this.
Implementing having 3 timezones for monitors is also too complicated/error prawn. Having two is likely pushing it already..
What I would agree with is how we display timezones that might have a smaller, non bold text below it like (server: 2024-.. 8:43 CEST)
when hovering over it in the UI.
I also think timezone by monitor is too complicated and it might be confusing over time. Also by a lot of modern application designs, they are using single timezone. To be honest, currently there are two timezones in the settings page, that is too complicated already. |
From a dev point of view I can't comment on complications of timezones, that's been complicated and overcomplicated from the start. From a user point of view. If I go to check a log in a server in California that went down 3 days ago at 5:33 AM I have to convert that to minus 9 hours which is... I literally have to look at a non digital clock now. So that's 8:33 PM the day before and now I can check the logs. Same way if I see a UI notification saying server is down 5 hours ago, well that just means 14 hours ago. In Sydney if a server went down 5 hours ago that just means it went down 14 hours into the future which didn't happen yet in EU. So if the server in Sydney went down 5 hours ago that would mean it went down 8 PM which is 11AM here, but it doesn't really matter what time it was in EU when that happened. I personally am not a fan of 'server went down 5 hours ago' anyway since then I have to do the math. I don't do the math because I can click and see the time stamp and that's what I find useful. So a simple offset would do the trick if there wasn't Daylight Saving Time. When I'm logged in to a remote server I like to look at the logs at the localtime and I think in terms of local time of where the server is at and not convert the time. Similarly if a European moves to US he shouldn't be converting meters to feet all the time, he really should think in miles. And when here think in Celsius etc. Also I don't undertstand the purpose of two timezones in the UI. I don't know what the 'server' timezone is. I couldn't get that to change the way UI displays time. That might be something to do with HA if there are multiple servers? What I'm talking about is not having three time zones for the UI. I'm talking about UI having one timezone and each Monitor having either the default timezone which is UI or having it's own timezone. I like this pull request because it shows the timestamp of the Monitor and that's useful. What is less useful, but still useful, is showing the UI timezone in Monitors. The attached video is actually clean. It shows the correct time of each Monitor and not the incorrect time. |
If I can add some inputs: During implementation, I considered scenarios like international businesses serving customers across different regions (e.g., Amazon). If you're serving customers in both Germany and the U.S., knowing when a service disruption occurs in their local time is important. A disruption at 4 a.m. would likely be less critical than one at 10 a.m. Additionally, for debugging, knowing a service went down at 10 a.m. local time could help identify issues like peak traffic, whereas using only one timezone across the board might lose such insights. The proposed solution wouldn’t add much complexity to the UI, as this feature would be 'hidden' within the settings of each monitor. It could even be further moved under the While working on the feature, I didn’t fully grasp the purpose of the I also agree with @GogoFC that the best approach would be to have one single default timezone while allowing each monitor to override it with a custom one aligned with the regions they serve. |
You both ignored the concerns that I and Louis had.
The real solution is to either not have cross timezones (monitor them in UTC, manually convert when that is important) or run an instance per timezone. The time of the day in local time when something went down likely should not play that much of a role in your workflow. If you are global, the oncall team will be on call for every incident, no matter the time of day where the incident is happening. |
Okay, understandable. Also upon checking similar monitoring tools, none have a custom monitor timezone feature.
Do you mean when hovering over single points datapoints in the 2024-10-17 12:45:32 with server timezone based on the value in Are there any other parts in the UI that should reflect this change? If it's still worth working on, I can make changes, otherwise, I'll close the PR. |
I'll try to exaplain. You're thinking about this wrong. What are we in the business of here? We're in the business of monitoring Monitors. We're not in the business of monitoring the UI or the server where UptimeKuma is running on. So you could remove both server timezone and UI timezone because it's not really important what time it is in Saigon when you live in Berlin. Where Saigon is the UI timezone and Berlin is the Monitor. If you had only timezones per each monitor, like Marcello implemented, then you wouldn't need the timezone for the UI or the server and then you could say it's a bit simpler. The server timezone of the linux host should be set on the actual linux host anyway and not overwritten manually.
Disagreement != ignoring. You could also say I didn't really disagree with your concerns, you could say I agreed that it's complicated because there's two extra timezones that we can do without :) , and I don't mean the monitor zones.
Having timezone per monitor isn't confusing. It makes it more simple. But if it is confusing to other people and they just want to think in UTC time then they already have that option to use the UI timezone. Server timezone I still don't see the point of. It doesn't do anything when set so it's as if we only actually have one UI timezone.
I mean it's fine as it is. That's what I do, I convert the hours in my head. I don't think in UTC time as I don't live in London at all. Many apps just use UTC because they don't want to deal with it. Upwork does payments in UTC, although I don't know what problem that solves as they could have just picked any timezone. This is just a tradition. Running multiple UptimeKumas just to set a timezone, well that's just a bad idea. No comment there :)
It doesn't play that much of a role, no. It is easier and cleaner however. Anyway this is how I think because I think in the terms of Monitors. Monitors are the things that matter here to me. Of course this is just a suggestion and my opinions. I tried to explain why it's simpler for me to have local datetime per monitor. And why it's confusing converting timezones. I don't have a team on call, I'm the team on call and I don't respond on notifications right away. I would also argue now that implementing Marcello's solution and removing the UI timezone completely is better, but that's only for me. Of course it should be left there for people who like to think in one timezone. But those who like a single timezone they don't need the second server timezone. I also still don't know the purpose of server timezone. |
I just googled Zabbix and as far as I remember it only had a global timezone. Plus, some old forum posts suggest to set all hosts to UTC because the db writes in UTC timestamps and so the data could be out of sync. That doesn't mean it's a good solution. It just means it's a very hard solution and no one wants to deal with it :) |
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma
Tick the checkbox if you understand [x]:
Description
Backend changes:
timezone
column to themonitor
table and ensure it's passed to the frontend.Frontend changes:
Monitor Timezone
setting is now available under theGeneral
section in each monitor setting.settings/general
.Fixes #5201
Type of change
Please delete any options that are not relevant.
Checklist
Screenshots (if any)
Screen.Recording.2024-10-16.at.19.51.06.mov
Please do not use any external image service. Instead, just paste in or drag and drop the image here, and it will be uploaded automatically.