Herkum has asked for the wisdom of the Perl Monks concerning the following question:

I am trying to write an on-call schedule and I want to keep times from overlapping. Example:

person   start end
person A 00:00-06:00
person B 06:00-12:00  # This is a good schedule

person A 00:00-06:00
person B 05:00-12:00  # This is bad because the times overlap.

Can anyone point me at module that I could use to help with this?

Update: Changed 'Calendar' to 'schedule'.

Replies are listed 'Best First'.
Re: Managing a on-call Calendar
by almut (Canon) on Feb 26, 2007 at 15:17 UTC

    Sorry, I can't recommend a specific module (at least not from the top of my head... and I'm sure you browse CPAN just as well as I can :)

    Anyway, before diving into implemention, it would probably help to define the task as clearly as possible: In case of a bad schedule, do you just want to warn, or somehow fix things automatically, or present a GUI that allows a user to shift slots around...? If automatic, how shall overlapping slots be dealt with? (e.g. should 00-06|05-12 become 00-05|05-12 or 00-06|06-12, etc.)   What to do in case of multiple overlaps? ... Generally, for data/time comparisons and conversions, there are quite a few modules on CPAN, like Date::Calc, Date::Manip, and friends.

[reply]
Re: Managing a on-call Schedule
by rhesa (Vicar) on Feb 26, 2007 at 15:28 UTC
    Net::ICal would be just the ticket for you, if it weren't for the fact that it's unmaintained. I'd take Chris Dolan's review of it to heart. See if you can patch it for yourself, or use an alternative.
[reply]
Re: Managing a on-call Schedule
by bsdz (Friar) on Feb 26, 2007 at 16:30 UTC
    There are various interval type modules on CPAN. By converting all your dates to epoch seconds and using Number::Interval, one could check to see whether the ranges overlap.

    To prepare a schedule you could use an iCal compliant application then convert the output to intervals. This could be done with Net::ICal as suggested above or Tie::iCal with Date::ICal.

[reply]
Re: Managing a on-call Calendar
by eric256 (Parson) on Feb 26, 2007 at 15:22 UTC

    One thought that comes to mind is to keep two tables. One would hold the schedules like you have above, the other would hold the times and who is scheduled for those times. Then when you added a new schedule, try and insert it into the second table (probably 1 record for your smallest segment of time), if you succeed then the rule is okay, otherwise force the user to retry. An alternative would be to build an insert trigger that does similar checking for you when you attempt to insert a record. The advantage of the first idea is that you can easily use your second table to generate a view that will show any gaps in the schedules as well as disallowing overlaps.


    ___________
    Eric Hodges
[reply]
Re: Managing a on-call Calendar
by dragonchild (Archbishop) on Feb 26, 2007 at 15:08 UTC
    Is there a reason you don't want to use GoogleCalendar or somesuch?
    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

      This is not a person Calendar but rather a Corporate on-call schedule for support groups. Identify the system, return the on-call for that support group.

      So I don't think that GoogleCalendar will work for me, in particular if the system that is down is the Internet access! :)

[reply]
        (I mentioned this in /msg, but it needs to be part of the public discussion on the topic.)

        The point isn't that GCal can(not) solve your problem. The point is that this is a well-solved problem. If your goal is to just get a system up, go buy one. If it's less than US$1000, then it's cheaper to buy than write, assuming that it'll take you about 12-14 hours (programmers generally cost a company, after all expenses, around $80/hr) to get an application up and running and that you'll write it perfectly the first time with the correct interface and handling all features that people might want to ask for.

        Maybe, that's a little unrealistic. So, maybe we should allocate about 80 hours over the next 6 months for you to work on this. That's $6400. I think you can find something for $6400 that'll meet your needs. Heck, a corporate license for the appropriate Exchange plugins should probably be less than that.

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

Back to Seekers of Perl Wisdom