You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.
Assignee: mfrosch
Status: Resolved (closed on 2014-03-12 22:44:57 +00:00)
Target Version: 1.11
Last Update: 2014-03-12 22:44:57 +00:00 (in Redmine)
Icinga Version: 1.10.0
Icinga Web Version: 1.10.1
IDO Version: 1.10.0
OS Version: FreeBSD 10.0-RELEASE
DB Type: MySQL
DB Version: 5.5.36
Browser Version: Any (Chrome, Firefox, IE..)
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 reproduce:
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 preventsall 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."
Provide TZ offset in Portal and use it in Duration calculation.
We calculate the offset between server and client, to calculate based
on server time.
Refs #5713
Revert "Command forms: Display date/time fields as UTC"
Smaller patch for 1.10.x - only revert the broken UTC behavior
This reverts commit d10f0b7eccfc66b334affc79ad7eb9ceff9a93ff.
Conflicts:
app/modules/Cronks/lib/js/Cronk/grid/CommandHandler.js
Refs #5713
Hey pekster,
Thank you for your good explanation of whats happening.
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.
Changes affect:
Duration fields in grids
Command Input fields
General support to provide timezone offset in the framework
The servertime on top now displays the timezone
I'll test it with multiple offsets and push it then for release.
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
Assignee: mfrosch
Status: Resolved (closed on 2014-03-12 22:44:57 +00:00)
Target Version: 1.11
Last Update: 2014-03-12 22:44:57 +00:00 (in Redmine)
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 reproduce:
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."
Changesets
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
Relations:
The text was updated successfully, but these errors were encountered: