Re^5: efficient determination of in/out of hours

You either need a mktime that is time zone aware (POSIX::mktime seems to know about DST but not about time zones), or an UTC variant, e.g. Time::timegm. Of course, the logic of $today instead of time needs to be applied, anyway. (I tried it out, seems to work)

In the tests, the first date (from the future) kills too many holidays :-) (you should either sort the test data before the test, or create a new ooh() when time traveling)

Update: The easiest fix would have been (in the originally posted version):

my $today = POSIX::mktime(0,0,0,(localtime)[3..5]);
while (<DATA>) { # read bank holiday file
   ...
[download]

Comment on Re^5: efficient determination of in/out of hours Select or Download Code

Replies are listed 'Best First'.
Re^6: efficient determination of in/out of hours by Random_Walk (Prior) on Oct 18, 2013 at 13:09 UTC
Even after working out `$today` in epoch, I still had the problem that I was storing bank hols as epoch. I would also need to look at each bank hol, and apply correct daylight saving time, before I could correctly establish its epoch start. I realised it was much easier to store bank hols as yyy:MM:DD and look at the date from localtime when I flip. I found another edge case around the transitions between saving/non saving. This could be bad as I may be treating alerts as OOH for an hour when the clocks go forward. I have added the following code to the main node to fix this `$valid = POSIX::mktime(@start, $date, $mnth, $yr); $valid += $add * (246060); # Check for daylight savings adjustment my $dst = $start[2] - +(localtime $valid)[2]; $valid += $dst * 60 * 60; my $now = time;` [download] Cheers, R. Pereant, qui ante nos nostra dixerunt!	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^6: efficient determination of in/out of hours
by Random_Walk (Prior) on Oct 18, 2013 at 13:09 UTC

Even after working out $today in epoch, I still had the problem that I was storing bank hols as epoch. I would also need to look at each bank hol, and apply correct daylight saving time, before I could correctly establish its epoch start. I realised it was much easier to store bank hols as yyy:MM:DD and look at the date from localtime when I flip.

I found another edge case around the transitions between saving/non saving. This could be bad as I may be treating alerts as OOH for an hour when the clocks go forward. I have added the following code to the main node to fix this

 $valid   = POSIX::mktime(@start, $date, $mnth, $yr);
 $valid  += $add * (24*60*60);
 # Check for daylight savings adjustment
 my $dst  = $start[2] - +(localtime $valid)[2];
 $valid  += $dst * 60 * 60; my $now = time;
[download]

Cheers,
R.

Pereant, qui ante nos nostra dixerunt!

[reply]
[d/l]
[select]