dylan bowden (dylan)2014-09-16 17:26 I'm pretty sure it's ok with the timezones because it has had a lot of testing over the past week. However, there are some implicit rules e.g. the timezone in your user preferences will be used when doing GET. Let me know if you find anything that can be reproduced. Date and times are indeed a major nuisance; the latest story took at least twice as long to implement than estimated.
Laurent Delaigue (ldelaigue)2014-09-16 17:22 Hi, It seems ok. Just make sure that the REST API sends and receives dates with "is_time_displayed" set to false when serialized like "2014-09-16". And I think there's another bug about the fact that the REST API does not currently take the timezone offset into account, I suppose this will be addressed when dealing with dates is "is_time_displayed" set to true. From my experience, dealing with timezone is one of the major cause of issues in software, so allow me to attract your attention on it ;)
dylan bowden (dylan)2014-09-16 15:41 Hi, In the latest version of Tuleap, all date fields in a tracker contain an extra property "is_time_displayed" that indicates whether the field uses time or not (it can be toggled in the "fields usage" section of the UI). There are some back-end rules that apply that I need to document but overall it ignores the time if the field has the property set to false. Is that information in the route enough or not? Status changed from Verified to Waiting for information
Laurent Delaigue (ldelaigue)2014-06-16 16:06 I update the severity of the ticket since I opened another ticket for the actual bug, this one should not have such a high severity.
Laurent Delaigue (ldelaigue)2014-06-16 15:36 I didn't ask for anything to be added overnight. If there is a better ticket somewhere to track opinions and arguments about changing date fields so they can display a date, I'd be happy to contribute to the discussion. I hadn't heard of this possibility before, hence this bug. I open the other bug right away.
dylan bowden (dylan)2014-06-16 15:31 Hi, the bugs need to be logged and fixed. Whether we should have a new type of field or not- maybe. However, it cannot be added overnight and I need the approval/ views of other developers.
Laurent Delaigue (ldelaigue)2014-06-16 15:04 Hi, What I've seen used elsewhere is a clear distinction between dates and datetimes. Don't you think you should introduce a new field type "datetime", which would clearly mean "a date with a time" rather than changing the semantics of date fields? In mylyn, Both types exist and can be managed. Besides, I've just remembered why we have attempted to manage dates without times. I've submitted this PUT /artifacts/24 {"values": [ { "field_id": 446, "value": "2014-01-09T00:00:00+00:00"} ], "comment": { "body":"Test for dates 2", "format": "text"}} And now Tuleap returns a different date, offset by 1 hour: { "field_id": 446, "label": "Start Date", "value": "2014-01-09T00:00:00+01:00" } This only seems to happend when we submit dates with "+00:00" at the end, otherwise dates seem correct. Of course we shouldn't have tried to workaround this problem, but anyway, I'm still convinced Tuleap would benefit from having 2 different types of fields for dates : date, and datetime. Do you want me to open another request for the date "+00:00" problem?
dylan bowden (dylan)2014-06-16 14:47 Hi, To give you context, we expect to be changing the date fields so that they accept time in the not too distant future. We knew this at the time of writing the API and that's why we went with that format. Should we make your change, the API would then need to be able to serve, accept and validate two different date formats which we are not yet convinced would be a good thing. Status changed from Waiting for information to Verified
Laurent Delaigue (ldelaigue)2014-06-16 14:31 Hi Dylan, I can explain the complete history of the problem, but I opened the tiket for the point that seems to me like being the root cause, and also the simplest and most secure way of solving the problem: These dates really should be transmitted without the time info to conform to their semantics. Currently we set a date to "2014-05-08", and Tuleap then sends for this field the following value: "2014-05-08T00:00:00+02:00" And this is incorrectly inteerpreted by us as "2014-05-07T22:00:00+00:00" from which we only keep "2014-05-07" since we only want a date, not a datetime. So there's a correction to be made on our side, but I opened the bug because I think it's not right to return a datetime for a field which is actually a date.
dylan bowden (dylan)2014-06-16 13:34 In fact, I'm not sure I totally understand your problem. Could you give me an example of a request/ response? I feel that there may be an alternative. Status changed from Acknowledged to Waiting for information
dylan bowden (dylan)2014-06-16 12:08 Hi, it is true that fields of type "date" do not have time info. I am trying to remember why we put them in the format we do and figure-out the impacts of changing them.
Laurent Delaigue (ldelaigue)2014-06-12 12:10 Increased severity because it induces a serious problem in the Tuleap connector (dates change at each submission)