Hi <!channel>! :wave: We're excited to share that...
# general
s
Hi <!channel>! 👋 We're excited to share that we're working on adding timezone support to SigNoz! This will allow you to view logs, traces, and other observability data in your preferred timezone. We'd love to hear from our community members who work in organizations with globally distributed teams. We have a question about how you handle timezones in your observability tools: Does your organization mandate that all teams should have same time zone set in your observability product (so that debugging is easy) or does it let the users keep the time zone of where the users are? Your insights will help us build a better timezone experience in SigNoz. Please share your experiences and preferences! 🙏
p
We usually keep each developer time zone. It help us with relatively time, for example, some error happened 7 hours ago. We occasionally switch times zone when event/error/trace under investigation is specified in absolutely time of company's timezone. For example, error happened on 9th Oct at 10:30 am Est.
a
In our organization, the timezone is based on the user's setting, but we convert all timezones to UTC before sending them to the backend. When the user retrieves the data, we convert it back to their local timezone accordingly.
s
+1 to the previous responses. We use time local to the dev in observability tools. When working with people in other timezones, we mention the time in UTC or directly send a link to the filtered logs.
a
in our experience, we use local time zone in the logs and reports from our tools, when working with other people with difference timezone its already detailed the exact UTC timezone so they can compare it themself
k
Similar to others here. We have engineers use their own timezones, but when sharing dashboards at a point in time, we share them in UTC time so whoever opens them sees them the same way and we can discuss them on terms of "notice 1:03am UTC"