User local timezone not taken into consideration when generating response time chart

[sudheeshb]

Describe the bug

I noticed that the time zone used in the 'response time' graph of the end points doesn't match with local time zone.

The time zone in the first page ( health status ) is correct. I am using Docker and passing the time stamp via '-e TZ=America/Los_Angeles' .

docker run -d
-p 9090:8080
-v /home/testDocker/Gatus/config:/config
--name gatus
-e TZ=America/Los_Angeles
--dns 192.168.1.1
--restart=unless-stopped
twinproduction/gatus

What do you see?

Different time zone in the response time graph

What do you expect to see?

All pages and graph should use the same time zone.

List the steps that must be taken to reproduce this issue

1. Start the application.
2. Check the time zone of the response time graph

Version

v4.0.0

Additional information

No response

[TwiN]

By default, Gatus uses UTC and doesn't really care about the user's local time.

It may however be possible to programmatically pass the user's local timezone while requesting for the response time graph. Something like

https://status.twin.sh/api/v1/endpoints/core_blog-article-43/response-times/24h/chart.svg?tz=America/Los_Angeles

or perhaps something like

https://status.twin.sh/api/v1/endpoints/core_blog-article-43/response-times/24h/chart.svg?tz=+06:00

where +06:00 is the UTC offset

[sudheeshb]

The main page ( Health Status ) page uses user's local timezone, but response time graph not. That is the concern.

[TwiN]

Yeah, that's because the response time graph is just a SVG generated on the backend, so unless we pass the timezone of the local user to the backend when generating said SVG, we won't be able to determine the visiting user's timezone.

That said, it should be fairly simple to implement.

All we have to do is add support for a query parameter here: https://github.com/TwiN/gatus/blob/2be81b8e1a5ecfdd67b5d124db7daa459f1f6662/controller/handler/chart.go#L32

and pass the user's local timezone as a query parameter here: https://github.com/TwiN/gatus/blob/2be81b8e1a5ecfdd67b5d124db7daa459f1f6662/web/app/src/views/Details.vue#L168-L170

[sudheeshb]

Is there any plan to fix this?

[michaelkrieger]

Is this not as simple as

if value, ok := os.LookupEnv("TZ"); ok {
    _zone, _ = time.LoadLocation(value)
}

sometime before line 95 of chart.go?

Would that not cause all of the time zones printed on the X axis to be in the timezone of the TZ environment variable much like the rest of the application?

[TwiN]

For the best user experience, you'd probably want to use the timezone of the user visiting the web page rather than the timezone of the OS, which is what I meant by https://github.com/TwiN/gatus/issues/321#issuecomment-1225045228

[michaelkrieger]

For the best user experience, you'd probably want to use the timezone of the user visiting the web page rather than the timezone of the OS, which is what I meant by #321 (comment)

Using the time zone of the system puts it in sync with the monitoring up/down messages so I think that’s the first step. This seems like something important as it’s the only UTC output im seeing in the app.

As for allowing adjustment, most monitoring systems use the system time that you’re monitoring, but now you’re adding per user configuration, as I don’t think there’s a way to reliably get the time zone from the browser and Gatus doesn’t do logins at this point.

[TwiN]

There's no need for per-user configurations. You can use something like Intl.DateTimeFormat().resolvedOptions().timeZone in the browser to get the user's timezone, and then you could pass this as a parameter to the endpoint for generating the chart usingthe user's timezone.

[kaseyhackspace]

Hi @TwiN , are the green ticks that shows timestamps using the local user timezone and not the backend server timezone, and thats why there is a need to pass the local timezone for the svg to be generated in local time?

[TwiN]

@kaseyhackspace That's correct. The backend stores all of this using unix time, and the frontend displays said unix timestamp using the browser's preferred timezone.

In contrast, the svg badge is, well, just svg, so it doesn't have javascript to retrieve the browser's preferred timezone and then display the unix timestamp accordingly.

[liamjones-pw]

Most people will figure it out intuitively but you could probably get away with just changing the title to make it explicit, i.e. RESPONSE TIME (UTC).