is it possible to avoid certain absolute dates?

[etodanik]

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]

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

[bunkat]

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]

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 [email protected] 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 #4 (comment).

[bunkat]

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]

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 [email protected] 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 #4 (comment).

[cappelaere]

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 [email protected] 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 #4 (comment).

[cappelaere]

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 [email protected] 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 #4 (comment).

[bunkat]

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]

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

On Jun 23, 2015, at 12:55 PM, bill [email protected] 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 #4 (comment).

[bunkat]

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]

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
[email protected]

Cell: 410 340 4868
Skype: patrice_cappelaere
gmail: [email protected]

On Jun 23, 2015, at 1:10 PM, bill [email protected] 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 #4 (comment).

[bunkat]

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.