More timezone problems - postpone_to.
Brought to you by:
aeby
postpone_to calculates a negative or excessive value for the postpone variable, because $now-$timezone may be greater than 24. This results in a negative postpone variable . $now-$timezone may also be negative resulting in a value of $postpone which is too large. This problem results in alarms that are generated immediately (negative postpone values) or postponed to the wrong time because the value of postpone is too high.
I assume the local time computations are all more or less broken :-((
It's probably worth a complete rewrite using Time::Local (hoping that
at least Time::Local handles local time correctly - probably needs some
testing)
Ok, finally I decided to refuse to use Time::Local :-))
There is a new bs_evgen::time_at() function trying to
determine correct GMT time given a local hour:min time.
It uses the localtime() function which is expected to
work correctly in any case (DST, "strange" timezones,
etc.)
postpone_to now determines the GMT time of the *next*
(local) hour:min via time_at() and subtracts the current
time to determine relative postpone values.
Oh, and there are probably a few hours around DST where
time_at() will fail.