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

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

by soonix (Prior)
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...

Replies are listed 'Best First'.
Re^4: efficient determination of in/out of hours
by Random_Walk (Prior) 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.


    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;


        Pereant, qui ante nos nostra dixerunt!

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1058680]
[Corion]: Meh. $effin_bad_system has an interface breakdown and then loads events in parallel with events overtaking one another instead of being processed sequentially
[shmem]: Discipulus: dunno, but we do all the time ^^
[choroba]: Discipulus I was taught so by a Londoner
[shmem]: Corion: very clear case of missing sequence number
[Corion]: shmem: Yeah. I guess they have a sequence number but distribute the events across threads or machines or whatever.
[karlgoethebier]: choroba: another chapter of "Learning English At The Monastry"?
[shmem]: Corion, well then... next issue, sequence number not a shared resource :P
[Discipulus]: shmem i'm searching it.. but failing i was sure was in Re: Let's Make PerlMonks Great Again! -- suggestions and dreams
erix recommends Vanished Kingdoms
[Corion]: shmem: Yeah, something like that. Not that that would be a solved issue. Simply process all events that come in from a single interface sequentially. Ah well.

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (13)
As of 2017-05-23 08:25 GMT
Find Nodes?
    Voting Booth?