Icinga2: TimePeriod objects should support timezones

[aleliga]

Hi,
as in the thread:
https://monitoring-portal.org/index.php?thread/40869-set-notifications-timeperiod-to-local-time-zone-not-utc/&postID=251295#post251295
the notification are set in UTC timezone, i had to convert my local time (Rome) to UTC and manually change it at every Daylight Saving change.
The same had to be done for different timezone clients

Maybe good the possibility to set timezone in host, to convert (automatically) notification time in local time (based on host timezone)

TY for all good work you done

[dnsmichi]

Do you have a specific configuration example and logs? I don't understand the issue here nor on the provided URL.

[aleliga]

Hi @dnsmichi
This is a feature request, not a bug, everything work fine.
Correct me if i'm wrong...
my setup for 9:00 to 17:00 it's like that:
Object 'T-8x5-summer-italy' of type 'TimePeriod':
friday = "07:00-15:00"
Because we are in CEST (in summer +2h from the UTC)
ours client in London are +1h from UTC and the same Timeperiod (in BST local time) has to be set like this:
Object 'T-8x5-summer-england' of type 'TimePeriod':
friday = "08:00-16:00"

In future release, could be good, if in the host definitions may be possible define the host timezone that, if set, calculate the start and ending time in local time
with a feature like that could be possible to set a global timeperiod that can be applied to all hosts in different timezones:
Object 'host-in-italy' of type 'Host'
* timezone = "CEST"
Object 'host-in-london' of type 'Host'
* timezone = "BST"

Object 'T-8x5-global' of type 'TimePeriod':
friday = "09:00-17:00"

[mdeguzis]

This would be very useful for us too. The general mantra is to keep things in UTC (especially for logs), but notifications and downtimes should have the ability to respect localtime. Meaning, our weekly sunday downtime would happen at 14:00 each time, not 13:00 or 14:00 based on DST.

Though... when setting up a recurring DT. not sure I understand. Since we are UTC-4, asking for 14:00 should have been 18:00, but had to use: sunday = "19:00-22:00" to achieve our sunday DT for 14:00 localtime. I am UTC-4 right now as the server time is 14:17 and local is 10:17

[root@icinga icinga-plugins]# date Sat Apr 7 14:46:36 UTC 2018

...yet I had to use 19:00 for the recurring dt object to target 14:00 for tomorrow with current UTC-4 in effect.

Maybe this is a misunderstanding on my part. I didn't want to open an issue if I just don't have enough coffee in my system yet :)

[peteeckel]

I strongly support this feature request.

Most data centres I deal with are running on UTC, but none of the support organisations are. The current implementation of the TimePeriods can't deal with this very at all ... while, i.e. "8to5" must be coded as "07:00-16:00" in the winter, it need to be changed to "06:00-15:00" when summer time becomes active.

Being able to specify a time zone in the TimePeriod object would magically fix this, and besides it would get rid of any uncertainty when configuring downtimes, notifications and checks.

[joncolas]

It would be great for us too!

[philomory]

As a global organization monitoring systems in remote offices and stores that get shut off at the 'end of the day' local time, this would be huge for us as well.

[Rayn0r]

I'd like to see such a feature as well.
We are using a Scheduler inside AWS to boot and shutdown machines according to local time. Since Icinga uses UTC, time periods between Icinga and the Scheduler differ by 1-2 hours depending on DST.

[ianbamforth]

+1, would be very useful

[mpounsett]

This would be very useful for notifications for services that have "next business day" service level agreements. Basing the notification time off of the server (which is probably in UTC, but in some organizations might be in a different local time zone than the service organization) makes configuring these notification time periods more complicated than necessary.

[dnsmichi]

Blocked by #7288.