Icinga/icingaweb2

Browser timezone information 'lost' after a day

Opened this issue · 0 comments

mstock commented

Describe the bug

At least when using the browser timezone, it seems that the timezone information gets lost after one day which then results in wrongly displayed timestamps. I also assume, but haven't tested this, that there's most likely a related issue shortly after DST changes.

To Reproduce

  1. Ensure that in the user settings, the timezone is configured to be taken from the browser.
  2. Take note of an example timestamp somewhere in the web interface (this should be a timestamp which is not updated regularly).
  3. Keep the browser tab/window with Icinga Web 2 open for more than a day and don't perform a page reload.
  4. After one day, still without page reload, compare the time noted and the current value. The currently displayed value will most likely be in UTC. After a page reload, this should be fixed. Alternatively, one could also compare timestamps between the long-running Icinga Web 2 frontend and a freshly loaded frontend in a second browser instance.

Expected behavior

Timestamps should always be displayed in the browser timezone if configured like this and this should not change after having Icinga Web 2 running for more than a day. They should also be correct right after DST changes.

Your Environment

  • Icinga Web 2 version and modules (System - About):
    • Icinga Web 2 Version: 2.11.4
    • Loaded Libraries:
      • icinga/icinga-php-library: 0.10.1
      • icinga/icinga-php-thirdparty: 0.11.0
    • Loaded Modules
      • graphite: 1.2.2
      • monitoring: 2.11.4
      • setup: 2.11.4
  • Web browser used: Firefox 115.9.1esr
  • Icinga 2 version used (icinga2 --version): r2.13.6-1
  • PHP version used (php --version): 8.2.7
  • Server operating system and version: Debian 12/Bookworm, both Icinga 2 and Icinga Web 2 installed from the packages provided by Debian.
  • date.timezone isn't set in any php.ini
  • /etc/timezone is set to Europe/Zurich on both client and server

Additional context

As far as I understand the cause of this issue, it seems like the timezone (as offset in seconds to UTC together with a DST flag) is stored in a cookie called icingaweb2-tzo whose value is then used in the PHP backend when rendering the HTML. When the cookie gets created, which seems to happen only when Icinga Web 2 is started and it does not exist, yet, it's set to expire after 1 day. So after a day, it's not sent anymore in the HTTP requests and the timezone is thus not used when rendering timestamps. Reloading Icinga Web 2 then recreates the cookie. As the cookie isn't updated for a day after its creation, this also means that the timezone information sent in the cookie is wrong for up to a day after a DST change.

I'm not sure how to best solve this, a simple but only partial fix probably would be to just call writeTimezone() regularly using something like setInterval(), however, that doesn't solve the DST issue and there still will be a short interval between the cookie expiration and the next execution of writeTimezone() where the cookie isn't sent. Simply increasing/removing the cookie expiration would cause more issues with DST changes (since the cookie wouldn't get updated anymore after a DST change), so I would not do that. An alternative might be to not use the timezone offset/DST flag, but the timezone name: It seems like this information is actually available to JavaScript through Intl.DateTimeFormat().resolvedOptions().timeZone. Passing that information to the backend, the backend should be able to correctly render timestamps based on its tzdata information. This would most likely also improve the currently slightly confusing display of the browser timezone in the settings (which does show a timezone name in the same timezone, but not the one that is actually set on the client).