Clarification required for WORKTIME for IfcTaskDurationEnum

Developers
1

The IfcTaskDurationEnum has three possible options:

Value Description
ELAPSEDTIME The time duration is based on elapsed time (24 hours per day, independent of calendar).
WORKTIME The time duration is based on work time (calendar-dependent).
NOTDEFINED The time duration is undefined.

ELAPSEDTIME seems pretty clear. For example, if after consideration of the applied calendar, the task ends up starting on 2021-01-01 and ending on 2021-01-07, then the elapsed time is P7D.

However, WORKTIME seems a little bit vague, there are two potential interpretations. For the two interpretations below, let’s assume in our example that the only applicable calendar is a Monday to Friday working time (i.e. Sat / Sun are not included), and the working time is from 9am to 5pm, so there are 8 hours of working time per day. So in 5 working days, or one calendar week, it is 40 hours. Let’s also assume that the start date of the task is on a Monday to keep the examples simple.

  1. The first interpretation is that WORKTIME is the actual time taken for the task, prior to analysis of the calendar. For example, it takes PT80H to do the task. This 80 hour duration can be then converted (say, in a UI) into Working Days, which is P10D, or 10 working days. Alternatively, it may be converted into Calendar Days (equivalent to ELAPSEDTIME), which is 12 elapsed days, since there is a weekend in-between the two working weeks. So, for this interpretation, I would expect to see PT80H stored in the duration attributes. If I change the calendar assignment, there is no need to change this value.
  2. The second interpretation is that WORKTIME is the Working Days taken for the task, with the calendar already applied to it (working times minus exception times). Therefore, I would expect to see P10D. Again, the software may analyse the calendar and convert to other representations. However, since this value is dependent on the calendar, anytime the user changes the calendar or start time, this field needs to be recalculated.

The advantage I see for the first interpretation is that it is the purest, rawest data, which can then be converted into different representations as befits the user. This also does not need updating whenever the calendar assignment changes. Also, from what I’ve seen in P6 XML exports, this is the value that they store. I have not yet checked MS Project.

The advantage I see for the second interpretation is that this is perhaps a more meaningful value for users, but requires more work for vendors to support and keep in sync, especially for inherited calendars.

Thoughts?

2

There is also further clarification required around different durations.

Let’s say we have PT40H as a duration in the first interpretation. Depending on the calendar, if our calendar was a 4x10hour working time, then this can be represented in the UI as P4D. If our calendar was a 5x8hour working time, then this can be represented in the UI as P5D. That is, the representation depends on the calendar. However, if we instead store P5D as a duration, then no matter how many hours in our calendar’s working times, the UI always represents it unchanged as 5 working days.

In the second interpretation, if we have PT40H, now things get confusing. No matter whether our calendar’s working time is 4x10hour working days (mon-thu) or 5x8hour working days (mon-fri) the PT40H remains unchanged. However, if we instead store P5D and had a 5x8hour working time previously assigned, and the user changes the calendar to a 4x10hour working time, then this value should change to P4D, should it not?

Colour me confused :slight_smile: