OK, I'm assuming those values in each column are some time designator (seconds since epoch or something similar?)

Since you are going to be doing a lot of time comparisons to figure out "did this job queue up but not start before this given time" or "did this job start but not finish as of this given time", seems to me your data structure needs to be something that's going to be ordered by time to simplify scanning the structure for the jobs.

Take the simplest case: how would you do this for just one queue? I'd be tempted to create three ordered arrays: one containing all the queue times, one with all the start time, and one with all the end times. The algorithm for stepping through the arrays, looking for jobs that werre queued up but not started, or started but not finished, as of a given time is pretty simple. In fact, I'd probably collect all three arrays into a hash, so I'd have a hash of arrays. There would be three keys: q_time, s_time, e_time, with the array of those times hanging off each key.

Extending this to 4 queues (or 7 queues or 2 .. maybe you can't predict how many queues you'll have each time?), then you just add another key to the front of your hash, with this key being the queue name. So now you have a hash of a hash of arrays.

Iterating over that to generate the report should not be too awful hard.

If a hash of a hash of arrays gives you a headache, start simple: do your algorithm with three separate arrays. Then put those arrays into a hash and see how it works. Then put another key in front of that hash and look again. It's not that tricky, really.

Hope that helps.

Edit: Actually, be very careful how you order your arrays. If you sort each array independently, you'll hose yourself good. You have to keep the queue, start, and end times for each job *together*. I realized I didn't point that out.