Hmm...it still seems broken.

If I understand the bug request, the requester wants to submit the times in the _system's_ timezone, but the JS is displaying the browser's timezone. That explains why I'm seeing what I'm seeing in the dialog.

But if that is the case, I expect that if I'm submitting browser-based times, they should be converted to local-based times - or at least have some sort of selector to say which timezone I'm submitting it for or something.

If I'm submitting times based on the system's timezone, I shouldn't be presented with local times.


On 3/11/2014 3:53 PM, Michael Friedrich wrote:
On 11.03.2014 20:47, Brian O'Neill wrote:
Strange, since it doesn't seem like I'm being converted to UTC, which
would be either 4 or 7 hours different.

You've got a multi instance setup with different timezones and when your
command is sent, this is the timezone of your local webserver. You are
probably asking for a setting for each instance in terms of timezone and
re-calculation of timestamps on commands being sent (given they are sent
in utc). Not sure if that is applicable or even possible to implement
with the current backend (or, command api).

The patch in 1.10.1 was applied due to this bug report:
https://dev.icinga.org/issues/4983



On 3/11/2014 3:30 PM, Kleber Rocha wrote:
This behaviour happens because this patch was applied in 1.10.1


                  oDef.format = 'Y-m-d H:i:s';

+                var now = new Date(),
+                    utcNow = new Date(now.getTime() +
now.getTimezoneOffset() * 60 * 1000);
+
                  if (!oDef.value) {
-                    oDef.value = new Date();
+                    oDef.value = utcNow;
                  } else if (oDef.value.match(/^now[ \+\-]\d+$/)) {
-                    oDef.value = new Date(new Date().getTime() +
1000 * Number(oDef.value.substr(3)));
+                    oDef.value = new Date(utcNow.getTime() + 1000 *
Number(oDef.value.substr(3)));
                  }

                  if (o.fieldName === 'expiretime') {

Always in UTC. I don't understood why this applied.

Att.
Kleber




2014-03-11 16:08 GMT-03:00 Brian O'Neill <one...@oinc.net
<mailto:one...@oinc.net>>:

    I'm using Icinga Web with several Icinga servers in various
    locations, including different timezones, although I'm experiencing
    an issue with it locally.

    My Icinga Web server, along with one Icinga instance running on the
    same box, is in the Pacific time zone ("America/Los_Angeles").
    System is set up in the correct zone (correct /etc/localtime file).

    php.ini has:
    date.timezone = "America/Los_Angeles"

    Other servers are in the Eastern time zone ("America/New_York").

    All interfaces display the correct time for their location. Icinga
    Web is showing the correct Server Time.

    But when I submit a scheduled downtime via Icinga Web, the downtime
    window displayed in the dialog starts off with times three hours
    ahead - i.e. the Eastern time zone. My browser _is_ in the Eastern
    time zone, but I've never known that to make a difference. Same for
    scheduling the next service check.

    Submitting the downtime to the local Pacific Icinga instance results
    in the downtime being offset by three hours, as was displayed in the
    dialog.

    Submitting to the Eastern instances results in it also being offset
    by three hours - it seems like the time shifting is correct, but it
    is starting off incorrect.

    I've tried setting the timezone in the AppKit module.xml and in
    translation.xml, but it didn't have any effect.

    There are no TZ variables anywhere that I am aware of.

    I can of course manually change the times in the dialog, but defeats
    the purpose and could be quite confusing to the users (although a
    per-user timezone configuration would be nice...as long as it
    translated to the local timezone...)

    Am I missing something elsewhere?





    _________________________________________________
    icinga-users mailing list
    icinga-users@lists.icinga.org <mailto:icinga-users@lists.icinga.org>
    https://lists.icinga.org/__mailman/listinfo/icinga-users
<https://lists.icinga.org/mailman/listinfo/icinga-users>




_______________________________________________
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

_______________________________________________
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users


_______________________________________________
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

Reply via email to