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
Most of my time periods are based on local time (our production planning, our support team are based on office hours).
However a few of them are tracking UTC-based events.
We are in a Daylight Saving Time country, so our offset to UTC (still) changes twice a year.
To the best of my knowledge, all Naemon (and Nagios) timeperiods use the process timezone ; there is no way to define a specific timezone for a timeperiod.
So far we handle local-time-based time periods with both the server timezone and/or the use_timezone parameter ; and for the UTC-based we update them manually twice a year.
While we can argue that countries will one day abolish DST (at least I believe in Europe it is the idea), and that changing a few configurations twice a year is not so huge ; I was wondering if extending the timeperiod definition to handle timezone would be useful to other use cases ; and would be an enhancement worth considering ?
The text was updated successfully, but these errors were encountered:
The use_timezone option simply sets the TZ environment variable. Afaik nothing else happens with that. Having a timezone setting for each timeperiod would indeed be nice. I am just a bit worried about what code implications this would have.
Most of my time periods are based on local time (our production planning, our support team are based on office hours).
However a few of them are tracking UTC-based events.
We are in a Daylight Saving Time country, so our offset to UTC (still) changes twice a year.
To the best of my knowledge, all Naemon (and Nagios)
timeperiod
s use the process timezone ; there is no way to define a specific timezone for atimeperiod
.So far we handle local-time-based time periods with both the server timezone and/or the
use_timezone
parameter ; and for the UTC-based we update them manually twice a year.While we can argue that countries will one day abolish DST (at least I believe in Europe it is the idea), and that changing a few configurations twice a year is not so huge ; I was wondering if extending the
timeperiod
definition to handle timezone would be useful to other use cases ; and would be an enhancement worth considering ?The text was updated successfully, but these errors were encountered: