DueTime interpretation ill defined

[pasi-paasiala]

Due date is understood as date in likely all BCF implementations. However, it is expressed as date with time component. This causes problems when transferring the due date between in BCF, since some implementations may strip of the time part and only use the date part. Also it is not specified what the time part should be. One possibility is to send due date as midnight UTC, but that hasn't been documented anywhere.

[GeorgDangl]

Hey @pasi-paasiala, thank you for the issue! As discussed in the call earlier today, we've found the DueDate property a bit hard to handle in actual implements.
Just as you described, in applications (that we know of), only the date part is used, e.g. due by June 21st, never the time part, e.g. due by June 21st at 14:00.

However, for the data type behind, we're using xs:dateTime, which contains a) a date, b) a time and c) a time offset (for time zone handling.

Now, this introduces the following problem:

• Assume I'm a user in Germany, being on CEST (UTC +2 hours). I create an issue and want it to be due at June 21st.
• My client will now save this as 2021-06-21T00:00:00+02:00, meaning my local time, midnight, with a time zone offset of +02:00 hours to UTC.
• This would map to 2021-06-20T22:00:00+00:00 in UTC, meaning the day before at 10 pm.
• Let's imagine a colleague from the UK opens the issue, so it's transformed in his application using his local timezone UTC+1 (I don't know if they're using DST there actually, so this example might be off, but it transports the message)
• That colleague now sees internally 2021-06-20T23:00:00+01:00, which is displayed as 20.06.2021, one day off from what was intended.

So, we have a mismatch between the spec and the actual usage:
Applications generally only work with a date component for due dates, while the schema currently wants an exact point in time (date + time of day).

We now need to find a solution for this😀

One possibility would be to change the due date to only represent a date, without any time zone offsets or any time component at all. This has the drawback of degrading the property to no longer support times, e.g. due by Monday at 17:00 would no longer be possible then.

Input from others would be greatly appreciated, especially from @jasollien, @wielinde and DDS (if anyone knows the GitHub username of Thomas Frankenmölle, pinging him in a comment would be great😀), since they've also got implementations but weren't present today.

Just some more thoughts from me: Changing the data type is a breaking change in the schema, and, in my opinion, too late - we've already finalized the v3.0 release, and communicated this to bSI. In the current situation, we could rather look into how to solve this issue with the current standard and gather some experience that will then influence the next version.

[wielinde]

In OpenProject the due date of work packages (issues) are in Date format. For our users it is rarely necessary to be an exact point of time. How to export this properly to BCF as DateTime indeed is not specified I believe. Currently we export the due dates as 00:00 UTC. However, that is simply due to the fact, that we did not care too much about that topic yet.

From our experience with DateTime fields on international projects is that people don't really know/care about that issue even outside our application. They have similar issues with their calendars etc. and are incapable to solve this. This becomes apparent when suddenly the week number is different in the US from the EU, like it is this year. This is when people start calling us.

[jasollien]

I understand the issue. However, by taking away the "time", the dueDate now ill have different meaning depending on the time zone. That will lead into other misunderstandings, for example: The due date is 15 hours later in the US than in Russia.

By having a time, the due will always be at the same time, even though it might be in the middle of the night for some countries.

That said: Bimsync always uses the time: 00:00UTC

[cschladetsch]

IMO, all data that refer to a time point should be UTC time with Date and Time and Offset.

[GeorgDangl]

We briefly discussed this in the call, we might not have to change the behavior, but document the conventions used when dealing with DueDates.