frigate
frigate copied to clipboard
blakeblackshear
Option to set timezone
What I am trying to accomplish and why in non-technical terms
I want to be able to set a timezone and configure Frigate to use that in the UI so that I can see, for example, when an event occurred in a way that makes sense when thinking about the location where the camera is installed and communicating with people onsite. When accessing Frigate from other timezones, using the browser timezone forces the user to manually add or subtract the time difference.
The solution I'd like
Set a timezone in Frigate's config and have it use that throughout the UI.
Alternatives I've considered
There is a Chrome extension that can be used to change the browser timezone, but that would mess up other websites that one wants in the local timezone.
I just realized I think this is a duplicate of https://github.com/blakeblackshear/frigate/issues/2838
Maybe partially? Some of #2838 seems to be about inconsistencies, which I think are fixed in 0.12? Storing everything internally in UTC is great and the correct way IMHO. My issue is only about presentation.
Will be nice to have that possibility. Set timezone for web ui as @ehn mention. Iam using privacy care browsers with small fingerprint, and i have those problems with wrong time presentations of clips :) For example in mull browser.
edit: I must add also that on that browser i get not only wrong time (from wrong timezone) but also PM/AM :) so that function only for web ui presentation will be nice :)
I pull latest version and timezone not work for me. I found in code
const timezone = config.ui?.timezone
this question mark its not a mistake?
I pull latest version and timezone not work for me. I found in code
const timezone = config.ui?.timezone
this question mark its not a mistake?
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining
i tried Europe/Warsaw and later pl-PL, but on my phone i still get am/fm and wrong hour
Am/pm will not change from this change, it's only timezone not locale. I'll have to test that and see but I tried a bunch of different America/ values and they worked as expected
Looks like my cleanup on the recordings side broke the timezone part, will take a look
So this works in most parts of the UI, but not all. When viewing snapshots, the embedded timestamp seems to be using the server time (which should be in UTC), disregarding the timezone setting in the config file.
@ehn yeah the option is under the UI category so wouldn't expect it to affect the snapshots timestamp, that would be a separate request (and honestly a separate option in the config most likely)
Oh, ok. Is there any conceivable situation where one would want different timezones for the UI and embedded timestamps?
Oh, ok. Is there any conceivable situation where one would want different timezones for the UI and embedded timestamps?
Probably not, but you never know. I suppose using the UI option wouldn't be an issue, but it may not be intuitive if a user was just looking for a way to set the timezone of the timestamp
I thought about this some more and was able to come up with one scenario where you might want different timezones for the snapshot timestamps and the surrounding UI: if you are pulling in video feeds from multiple sites in different timezones. Not sure if that's a reasonable use case, though.
I have two sites that are 6–7 hours apart. Currently, I'm running two Frigate instances, which makes more sense to me, but I suppose I could run just one, in which case I'd want per-camera timezone settings. It seems a bit excessive, though. Arguably, in the vast majority of cases, there will be a site timezone that should be used throughout the entire UI, including embedded timestamps.
One counterargument is that, while the UI timezone can be changed, once something is written to a snapshot image, it's there forever. Based on that, one could argue that embedded timestamps should always be in UTC. Then I'd also argue for using ISO 8601 format including the timezone to make that clear: 2023-02-17T08:06:54+00:00.
One small issue remains: If you go to recordings, it will say something like "Dates and times are based on the browser's timezone Asia/Singapore". This is technically incorrect if you have set the timezone in the config file. Just removing "browser's" would be a simple fix that doesn't require keeping track of where and how the timezone was set.
(Let me know if you want me to create a new issue for this.)
One small issue remains: If you go to recordings, it will say something like "Dates and times are based on the browser's timezone Asia/Singapore". This is technically incorrect if you have set the timezone in the config file. Just removing "browser's" would be a simple fix that doesn't require keeping track of where and how the timezone was set.
(Let me know if you want me to create a new issue for this.)
Fixed for the next beta
@NickM-27 I don't think there was ever a conclusion in this thread about how to handle the timezone of embedded timestamps, which currently seems to be UTC (or host timezone, which IMHO should always be UTC for a server regardless of physical location). Should it adhere to the UI config? Should there be a separate setting? Should this be discussed in a separate issue?
Nick is taking some time off this week, but he messaged me about this already and we will get it fixed for the next beta when he returns.
@ehn if suggest making a feature request for timezone configuration in the snapshots. That's a separate change unrelated to anything done in 0.12 (it works the same as before)