Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DueTime interpretation ill defined #346

Open
pasi-paasiala opened this issue Jun 21, 2021 · 5 comments
Open

DueTime interpretation ill defined #346

pasi-paasiala opened this issue Jun 21, 2021 · 5 comments

Comments

@pasi-paasiala
Copy link
Contributor

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
Copy link
Member

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
Copy link

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
Copy link
Contributor

jasollien commented Jul 28, 2021

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
Copy link

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

@GeorgDangl
Copy link
Member

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

@GeorgDangl GeorgDangl self-assigned this Nov 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants