bunkat / schedule

Automatically schedules tasks, work items, meetings, reservations, etc. Schedule takes into account working hours, holidays/days off, people's work schedule/vacation time, as well as task dependencies.
http://bunkat.github.io/schedule/
MIT License
427 stars 87 forks source link

is it possible to avoid certain absolute dates? #4

Open etodanik opened 9 years ago

etodanik commented 9 years ago

I'm looking at a use case where I defined availabilities, tasks and generate them.

However, sometime in the future I might come back and with those same availabilities try to generate more tasks, being aware of the previous batch of tasks.

So say , for an elevator that is available between 16:00 - 20:00, I would like to be able to input and "remember" that there is a reservation already on Monday 14:00 - 14:15

cappelaere commented 9 years ago

I have a similar problem: I want to make a resource available at some date except between 12:00am and 1:00pm

bunkat commented 9 years ago

You can use a Later exception schedule with the full date constraint to make certain absolute time periods unavailable:

later.parse.recur().except().on(new Date('2013-03-21T11:30:00')).fullDate()

Or if you want to just make blocks of time unavailable, you can do that as well:

later.parse.recur().except().between(0, 13).hours()

Or

later.parse.recur().except().after('00:00').time().before('13:00').time()
cappelaere commented 9 years ago

I would have thought so but this example does not seem to work:

var later = require('later') var schedule = require('schedulejs')

var today = new Date(Date.UTC(2015,6,15,6,0,0))

var startExclusion = new Date(Date.UTC(2015,6,15,6,30,0)) var endExclusion = new Date(Date.UTC(2015,6,15,7,30,0))

schedule.date.UTC();

var tasks = [ {id: 1, duration: 30, resources: ['A']}, {id: 2, duration: 30, resources: ['A']}, {id: 3, duration: 30, resources: ['A']}, ];

// Define a set of resources var r1 = { id: ‘A’ }

var resources = [ r1];

r1.availablility = later.parse.recur() .except() .after(startExclusion).fullDate() .before(endExclusion).fullDate()

// Create the schedule for all of the tasks var s = schedule.create(tasks, resources, null, today);

console.log("Today", today.toISOString())

for(var id in s.scheduledTasks) { var st = s.scheduledTasks[id]; console.log('id:',id ); console.log('Start:', new Date(st.earlyStart).toISOString() ); console.log('Finish:', new Date(st.earlyFinish).toISOString() ); }

*\ Output>

Today 2015-07-15T06:00:00.000Z id: 1 Start: 2015-07-15T07:00:00.000Z Finish: 2015-07-15T07:30:00.000Z id: 2 Start: 2015-07-15T06:30:00.000Z Finish: 2015-07-15T07:00:00.000Z id: 3 Start: 2015-07-15T06:00:00.000Z Finish: 2015-07-15T06:30:00.000Z

On Jun 22, 2015, at 6:34 PM, bill notifications@github.com wrote:

You can use a Later exception schedule with the full date constraint to make certain absolute time periods unavailable:

later.parse.recur().except().on(new Date('2013-03-21T11:30:00')).fullDate() Or if you want to just make blocks of time unavailable, you can do that as well:

later.parse.recur().except().between(0, 13).hours() Or

later.parse.recur().except().after('00:00').time().before('13:00').time() — Reply to this email directly or view it on GitHub https://github.com/bunkat/schedule/issues/4#issuecomment-114287727.

bunkat commented 9 years ago

May need to add a valid schedule to your exception schedule (recur().every(1).minutes().except()...). You should use Laterjs to validate the resource schedule to make sure it produces what you think it should.

The fullDate() constraint isn't documented because it was never fully tested unfortunately and may not be working correctly with exception schedules.

cappelaere commented 9 years ago

Ney, Sorry! Does not work with every(30).minute()… Does not work when I remove fullDate()… Does not work with time() … Bummer! Pat.

On Jun 22, 2015, at 8:31 PM, bill notifications@github.com wrote:

May need to add a valid schedule to your exception schedule (recur().every(1).minutes().except()...). You should use Laterjs to validate the resource schedule to make sure it produces what you think it should.

The fullDate() constraint isn't documented because it was never fully tested unfortunately and may not be working correctly with exception schedules.

— Reply to this email directly or view it on GitHub https://github.com/bunkat/schedule/issues/4#issuecomment-114312131.

cappelaere commented 9 years ago

r1.availablility = later.parse.recur() .except() .after("6:30:00").time() .before("7:30:00").time()

did not work either Pat.

On Jun 22, 2015, at 6:34 PM, bill notifications@github.com wrote:

You can use a Later exception schedule with the full date constraint to make certain absolute time periods unavailable:

later.parse.recur().except().on(new Date('2013-03-21T11:30:00')).fullDate() Or if you want to just make blocks of time unavailable, you can do that as well:

later.parse.recur().except().between(0, 13).hours() Or

later.parse.recur().except().after('00:00').time().before('13:00').time() — Reply to this email directly or view it on GitHub https://github.com/bunkat/schedule/issues/4#issuecomment-114287727.

cappelaere commented 9 years ago

Hey Bill,

I think I fixed one problem but I have a fundamental question for you.

When I say this: r1.availability = later.parse.recur() .except().after('06:30').time().before('7:00').time()

I expect that the first task could run from 6:00 until 6:30 and the second task after 7:00 The first task fails because of a 1mn overlap requirement. What was the intent of the requirement? Thanks, Pat.

On Jun 22, 2015, at 8:31 PM, bill notifications@github.com wrote:

May need to add a valid schedule to your exception schedule (recur().every(1).minutes().except()...). You should use Laterjs to validate the resource schedule to make sure it produces what you think it should.

The fullDate() constraint isn't documented because it was never fully tested unfortunately and may not be working correctly with exception schedules.

— Reply to this email directly or view it on GitHub https://github.com/bunkat/schedule/issues/4#issuecomment-114312131.

bunkat commented 9 years ago

The after constraint is inclusive and the before constraint is exclusive. Anything between 6:30:00 and 6:59:59 will be considered conflicting.

cappelaere commented 9 years ago

But a task that ends at 6:30am should be ok, right?

On Jun 23, 2015, at 12:55 PM, bill notifications@github.com wrote:

The after constraint is inclusive and the before constraint is exclusive. Anything between 6:30:00 and 6:59:59 will be considered conflicting.

— Reply to this email directly or view it on GitHub https://github.com/bunkat/schedule/issues/4#issuecomment-114571729.

bunkat commented 9 years ago

Yes, a task that ends at 6:30 should be treated internally as ending immediately before 6:30 and should not conflict. When the scheduler schedules a task, it basically just adds a new after and before constraint to the task/resource which has the same semantics.

From resource-manager.js:

res.schedule.exceptions.push({fd_a: [start], fd_b: [end] });
cappelaere commented 9 years ago

Sorry but I cannot get it to run. Here is a my test case. You can just add it to the test suite. I am printing the schedule to check what is going on... Thanks, Pat.

Pat Cappelaere pat@cappelaere.com

Cell: 410 340 4868 Skype: patrice_cappelaere gmail: cappelaere@gmail.com

On Jun 23, 2015, at 1:10 PM, bill notifications@github.com wrote:

Yes, a task that ends at 6:30 should be treated internally as ending immediately before 6:30 and should not conflict. When the scheduler schedules a task, it basically just adds a new after and before constraint to the task/resource which has the same semantics.

From resource-manager.js:

res.schedule.exceptions.push({fd_a: [start], fd_b: [end] }); — Reply to this email directly or view it on GitHub https://github.com/bunkat/schedule/issues/4#issuecomment-114574918.

bunkat commented 9 years ago

Sorry about that. I'm no longer using this code and only left it posted in case it might be helpful to somebody else. Looks like there are definitely issues so I wouldn't suggest relying on this code for anything important.