Aspose.Tasks, Finish field returns wrong date

Hi guys,

I was trying to upgrade Aspose.Tasks library from 23.6 to 25.9 and found different behavior dealing with Finish field.
I tried the same code in different Aspose.Tasks versions and figured the different behavior starts happening from 25.2 version.

I’ve attached sample solution which shows the issue.

Could you have a look?

Thanks
AsposeTaskFinishDateIssue.zip (7.6 KB)

@sentientsoft

It appears you are encountering an issue with the Finish field in the Aspose.Tasks library after upgrading from version 23.6 to 25.9, particularly noting a change in behavior starting from version 25.2.

To resolve this, I recommend reviewing the release notes and known issues for the versions you are using. Changes in behavior may result from updates in how certain fields are calculated or managed.

If you have a sample solution that illustrates the issue, consider sharing it on the Aspose forum for more focused assistance from the community or the support team. They can provide insights based on the specific code and data you are working with.

If you have further questions or need additional assistance, please feel free to reach out!

I have attached a zip file that contains visual studio solution. You can see the bug behavior easily

@sentientsoft ,
thank you for the example. We need some time to investigate the issue.

@sentientsoft ,
the behavior of task recalculation was changed in 25.2.
2023-12-25 (and 2023-12-24) are non-working days.
Setting of task percent triggers recalculation of task dates which, in turn, adjusts task finish date to the nearest working day end.

Do you have a scenario where task finish date should be on non-working day?

Hi Vasiliy,

Thanks for the quick response.
No we happen to have a unit test that simply sets date and extract to update an object based on mpp file. The test scenario was setting 25th as finish date and it was failing after upgrade.
Change calculate makes sense.
Could you confirm that the same type of calculation happens in Microsoft Project?
For example, if I open and create a new project file using Microsoft Project, set the Finish date to be 25th, would Microsoft Project set the Finish date to be 22th (or nearest working day end)? I’d love to test it by myself but I don’t have Microsoft Project installed.

Thanks

@sentientsoft ,
Microsoft Project in this case marks 25th as “implicit” (not visible in Calendar/Exceptions settings tab) calendar exception and treats this day as working.

The same logic is not implemented in Aspose.Tasks. I will add the corresponding enhancement to our issue tracking system.

@sentientsoft
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): TASKSNET-11594

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

Hi Vasiliy,

I found another odd behavior. So I tweaked test code to use 22 Dec instead of 25th so that it won’t fall into public holiday.
When I run code below (slightly tweaked from previously shared code)

image.png (69.1 KB)

I get 21st as screenshot attached. Only way to get the expected date is I need to set the time like new DateTime(2023, 12, 22, 23, 59, 59)

Is this intended behaviour? It looks like a bug…

Regards

@sentientsoft ,

new DateTime(2023, 12, 22) results in “2023-12-22 00:00:00” date. It’s a non-working time. The nearest working time is 2023-12-21, 5:00:00 PM.

It would be more user-friendly to add logic similar to MS Project: when the user sets a date without specifying a time, the system automatically adds the default end time from the project’s settings.

The API given DateTime with Time == 00:00:00 cannot distinguish whether the user created it without specifying a time or intentionally set it to midnight. In other words, in .NET we cannot distinguish between d1 and d2:
var d1 = DateTime(2023, 12, 22);
var d2 = DateTime(2023, 12, 22, 0, 0, 0);

Thus adding the described logic would be frustrating for users who intentionally want to set the finish time to new DateTime(2023, 12, 22, 0, 0, 0).

I recommend explicitly specifying times according to the relevant calendar (project’s, task’s, or resource’s calendar).
For example, the default calendar for a project created with the default ctor (var project = new Project()) is a 5-day schedule with working hours 08:00 - 12:00, 13:00-17:00.

In your code, you could set dates and times like this:
task.Start = new DateTime(2023, 12, 1, 8, 0, 0);
task.Finish = new DateTime(2023, 12, 22, 17, 0, 0).

There is another concern: once the issue TASKSNET-11594 is fixed, setting
task.Set(Tsk.Finish, new DateTime(2023, 12, 22))
will be interpreted as explicitly setting finish to a non-working time 2023-12-22 00:00:00.
As a result the interval [2023-12-21 17:00:00 - 2023-12-22 0:00:00] will be marked as implicit working time (as MS Project does when you set finish to 2023-12-22 0:00:00) which can lead an unexpected results.