Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

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

by soonix (Priest)
on Oct 17, 2013 at 20:39 UTC ( #1058680=note: print w/ replies, xml ) Need Help??


in reply to Re^2: efficient determination of in/out of hours
in thread efficient determination of in/out of hours including Bank Holidays

That's mathematically the same. (If 86400 were a power of 2, the most efficient way 'd be >> and <<.) However time and mktime refer to different timezones. Unless you happen to be in Iceland, there are some hours when this works wrong...
Update: I posted this while you updated your post :-)
I'm not at my computer, but perhaps something like mktime(gmtime) for determining today's midnight could work...


Comment on Re^3: efficient determination of in/out of hours
Select or Download Code
Re^4: efficient determination of in/out of hours
by Random_Walk (Parson) on Oct 18, 2013 at 05:57 UTC

    The core of the problem is that I am incorrectly storing bank holiday start points in epoch seconds based on UTC0. Of course they actualy start at localtime == 00:00:00. I think I need to revise the code to store bank hols as (YYYY-1900):MM:DD, then compare to the appropriate fields of locatime($epoch).

    original node updated with fixed code.


    Cheers,
    R.

    Pereant, qui ante nos nostra dixerunt!

      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 ...

        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;

        Cheers,
        R.

        Pereant, qui ante nos nostra dixerunt!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1058680]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (19)
As of 2015-07-01 15:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (6 votes), past polls