Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #5713] Inconsistent form timezone handling in Icinga-Web 1.10.1 #1267
This issue has been migrated from Redmine: https://dev.icinga.com/issues/5713
Created by pekster on 2014-03-05 18:09:08 +00:00
With the changeset from Bug #4983 (commit d10f0b7) the handling of time form entries in Icinga-Web is inconsistent. The default form entry shows UTC time (per the commit) but the value is then taken as local time when fed to Icinga, causing offsets for anyone who doesn't use UTC as system time.
In my case, the system timezone (of both the server and client) is set to US Central time ("America/Chicago") in both the OS and php.ini with date.timezone. Icinga-web (starting with 1.10.1) shows the expected local time on the main page after "Servertime:" near the top.
My recommendation on a fix is to revert the above commit, then re-visit the solution to Bug #4983 to provide a method to translate the field inputs to a users local time, not blindly use UTC as the form defaults (which then get interpreted as localtime.)
To demonstrate the issue, set the OS (and php.ini) to some non-UTC time (best to use a timezone behind UTC so checks are delayed) and go to any service, then select 'schedule next service check.'
Expected behavior is have the default time schedule the check now (without changing the time.) The actual behavior is to delay the check for the UTC minus localtime difference.
In my case, this prevents all active checks of the service for 6 hours verses what the 1.10.0 behavior did. Users shouldn't have to manually reset form time to local time for scheduling things to happen "now."
2014-03-12 17:56:19 +00:00 by mfrosch b9b48ea
2014-03-12 21:29:28 +00:00 by mfrosch 1c7584f
2014-03-12 21:56:03 +00:00 by mfrosch c216de1
2014-03-12 22:05:28 +00:00 by mfrosch c8d96b5
2014-03-12 22:42:38 +00:00 by mfrosch 2c88a08
2014-03-12 22:44:07 +00:00 by mfrosch d95ab14
2014-04-01 11:40:22 +00:00 by mfrosch 38e17f3
Updated by mfrosch on 2014-03-12 22:11:44 +00:00
Basically the change in #4983 was not a good idea, but I guess only a few noticed it really...
I prepared a few fixes regarding handling of timezones between server and client.
The idea to go is that the timestamps and inputs in the frontend matches the timezone of the server. This was not handled correctly before, and was even worse in 1.10.1.
I'll test it with multiple offsets and push it then for release.