Uploaded image for project: 'ZABBIX BUGS AND ISSUES'
  2. ZBX-4437

Recurring maintenance periods are correct only for server's time zone. It's not very clear when using frontend on different time zone.




      start_time is not a proper timestamp but only a measure for "seconds since the day started". Thus it is not passed through a timestamp function that translates it from local time to UTC. Thus the entered value is incorrectly stored as is and then interpreted in UTC.

      This only affects recurring maintenance periods, "only one time" periods are handled properly (because they are proper timestamps).

      [20:58:49] <bantu> Seems to be related to this line in maintenance.php
      [20:58:49] <bantu> $new_timeperiod['start_time'] = $new_timeperiod['hour'] * SEC_PER_HOUR + $new_timeperiod['minute'] * SEC_PER_MIN;
      [20:59:40] <bantu> Need to subtract something like date('Z') there and add date('Z') before display.
      [21:02:57] <bantu> display seems to be in shedule2str()
      [22:20:08] <Richlv> <bantu> but the stored values should be in UTC because otherwise you'd get the problems explained above
      [22:20:47] <bantu> ?
      [22:21:33] <Richlv> time values are stored as unix timestamps
      [22:21:36] <Richlv> which by definition is utc :)
      [22:21:40] <Richlv> (sorry, slow wifi here)
      [22:21:55] <bantu> yeah, exactly
      [22:21:59] <bantu> mktime() does that for you
      [22:22:35] <bantu> but start_time is not a timestamp
      [22:22:55] <bantu> but still a time
      [22:22:59] <bantu> so you have to do it manually
      [22:23:24] <Richlv> hmm ? timestamp = time, just in a specific format :)
      [22:24:05] <bantu> active_since is 1323548100
      [22:24:05] <bantu> start_time is something like 79200
      [22:24:30] <Richlv> oh, right
      [22:24:31] <bantu> the first one is a timestamp, an absolute point in time
      [22:24:45] <Richlv> as in "seconds since the beginning of the day" ?
      [22:24:54] <bantu> yup
      [22:24:56] <bantu> start_time that is
      [22:25:02] <Richlv> hah, i think i get what you are saying
      [22:25:16] <Richlv> changing timezone would interpret the value differently
      [22:25:37] <bantu> I don't know about that
      [22:25:40] <bantu> I don't think so
      [22:25:52] <bantu> I think it is right now always interpreted in UTC.
      [22:25:59] <bantu> so fixing this would not change behaviour
      [22:26:19] <bantu> (for already stored values)
      [22:27:12] <bantu> but would fix behaviour for new values
      [22:27:30] <Richlv> the problem is that entering 01:00 wiith a +3 timezone results in a different day when timezone is changed to -3 ...
      [22:27:45] <Richlv> or vice versa
      [22:27:50] <bantu> right
      [22:27:52] <Richlv> can't think too well anymore :)
      [22:28:05] <bantu> so the solution is more complicated
      [22:29:31] <bantu> maybe just allow start_time to be negative


        Issue Links



              Unassigned Unassigned
              bantu Andreas Fischer
              10 Vote for this issue
              10 Start watching this issue