Skip to content
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.

[dev.icinga.com #5713] Inconsistent form timezone handling in Icinga-Web 1.10.1 #1267

Closed
icinga-migration opened this issue Mar 5, 2014 · 3 comments

Comments

@icinga-migration
Copy link

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)

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 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

Revert "Command forms: Display date/time fields as UTC"

This reverts commit d10f0b7eccfc66b334affc79ad7eb9ceff9a93ff.

Conflicts:
	app/modules/Cronks/lib/js/Cronk/grid/CommandHandler.js

Refs #5713

2014-03-12 21:29:28 +00:00 by mfrosch 1c7584f

Include timezone in servertime

Refs #5713

2014-03-12 21:56:03 +00:00 by mfrosch c216de1

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

2014-03-12 22:05:28 +00:00 by mfrosch c8d96b5

Added timezone offset handling to command datefields.

Refs #5713

2014-03-12 22:42:38 +00:00 by mfrosch 2c88a08

Fixed offset calculation between client and server.

Javascript returns positive offsets for negative timezones.

Refs #5713

2014-03-12 22:44:07 +00:00 by mfrosch d95ab14

Merge branch 'fix/timezone-handling-5713' into next

Fixes #5713

2014-04-01 11:40:22 +00:00 by mfrosch 38e17f3

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

Relations:

@icinga-migration
Copy link
Author

Updated by mfrosch on 2014-03-10 10:11:30 +00:00

  • Target Version changed from 1.10.1 to 1.11

@icinga-migration
Copy link
Author

Updated by mfrosch on 2014-03-12 22:11:44 +00:00

  • Status changed from New to Assigned
  • Assigned to set to mfrosch
  • Priority changed from Normal to High
  • Done % changed from 0 to 80

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.

Cheers
Markus

@icinga-migration
Copy link
Author

Updated by mfrosch on 2014-03-12 22:44:57 +00:00

  • Status changed from Assigned to Resolved
  • Done % changed from 80 to 100

Applied in changeset d95ab14.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant