Jump to content

On Hold for 6 months...how is that worked out?

Guest Paul Alexander

Recommended Posts

Guest Paul Alexander


I've got a request which needs to be put on hold for 6 months - but the on-hold 'timer' is making some weird calculations!

I've set my 'on hold period' to be 6 months:




But the actual on-hold time is set to come off in about 5 and a half months, at a completely different time of day. 




Is there a setting where I can just set the request to come off in 6 WHOLE months, so that, rather than what is there at the moment, it comes off hold on the same DAY of the month, but 6 months later please?



Link to comment
Share on other sites

Guest Paul Alexander

Hi @Victor

Um...no it doesn't really help (thanks though! :) )

What I'm looking for is a timer which will put the request on hold until the same day of the month, but 6 months in the future. Using the timers won't work, I don't think, because there will be Bank Holidays and other 'things' in the working calendar which will skew this date. 

So just a tool which can take todays date, add 6 months to it, and give me that date would be useful. Could this be something which could be included in the iBridge utilities maybe please?



Link to comment
Share on other sites

Guest Paul Alexander

Just did some working out, and it seems that one month for these on-hold nodes is actually 4 weeks!

So, if I put a request on hold for 2 months it goes onhold for 8 weeks (and one hour, which is, presumably because the clocks go forward!).....and NOT 2 months:




Which still doesn't help me with the 6 month problem :)





Link to comment
Share on other sites

1 hour ago, Paul Alexander said:

it seems that one month for these on-hold nodes is actually 4 weeks!

@Paul Alexander Yes. Best work with seconds. So on the node:

1 minute = 60 seconds

1 hour = 3600 seconds

1 day = 86400 seconds

1 week = 604,800 seconds

1 month = 604,800 * 4 weeks = 2,419,200 seconds

1 year = 31,556,926 seconds

The node needs to work with a common denominator and that is the second. Issue is, as you noticed, it will not always match the calendar value.

Link to comment
Share on other sites

@Paul Alexander

I've reviewed the code and currently months are as you say just being determined as a 4 week period, this is likely just a legacy choice due to ambiguity over what is defined as a month e.g. 28 Days in Feb/31 Days in March etc.

I'll make an enhancement to this flowcode so that when you are defining months and we are not working against a working time calendar, we will treat "a month" as the same day in the following month etc.. so in your example 26th Feb will become 26th August, however there will of course be some exceptions e.g. adding 1 month to Jan 30th with result in March 2nd rather than a non existent February day.

All of the datetimes are calculated and stored in UTC and formatted in the UI according to your regional settings, so the value is not one hour ahead in the database it is just being displayed as one hour ahead due to being in BST at the date in August.

As an alternative until this is available you could:
1.  Apply a number of days e.g. 182 days for 6 months or any of the smaller time denominations as @Victor suggests above (accepting the calendar day may not match)

2. If you have any way to make the exact date available to the BPM at that point (e.g. a date selected custom field on a request) then you can pass in an exact date to the "On Hold Until" parameter of that flowcode which allows you to set the exact datetime.



Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...