🦔 PostHog provides open-source web & product analytics, session recording, feature flagging and A/B testing that you can self-host. Get started - free.
Timezone names on their own aren't that useful because they're basically a harder-to-use version of displaying events by city/region. Displaying them by offsets, however, can prove to be valuable. We're doing some magic to calculate the offset instead of simply using something like timezoneOffset because toString is one of the only functions in Clickhouse that allows us to use a dynamic timezone versus a hardcoded one. This might have some performance implications, we'll figure it out soon :). To workaround that, we're converting to a string, then parsing that back to a date, and getting the unix timestamp. Comparing the UNIX timestamp in a specific timezone versus the value at UTC allows us to get the offset at that day.
See #26376
Changes
Does this work well for both Cloud and self-hosted?
Timezone names on their own aren't that useful because they're basically a harder-to-use version of displaying events by city/region. Displaying them by offsets, however, can prove to be valuable. We're doing some magic to calculate the offset instead of simply using something like
timezoneOffset
becausetoString
is one of the only functions in Clickhouse that allows us to use a dynamic timezone versus a hardcoded one. This might have some performance implications, we'll figure it out soon :). To workaround that, we're converting to a string, then parsing that back to a date, and getting the unix timestamp. Comparing the UNIX timestamp in a specific timezone versus the value at UTC allows us to get the offset at that day.See #26376
Changes
Does this work well for both Cloud and self-hosted?
Yep
How did you test this code?
Comprehensive unit test + manual UI testing