bobjolliffe
commented
11 years ago Yes this relates to my issue https://github.com/facilityregistry/fred-api/issues/30
Matt has flagged this as resolved but I agree that it is still a bit unclear just diodn't have time to expand.
Currently we now just say "All dates should follow ISO 8601". ie. no longer mentioning timezones at all. And I see all the examples show dates with explicit utc timezones.
Some guidance is required here for a couple of reasons. ISO8601 is not an "open" standard in the sense that it is freely available. So must people won't have a copy and will be referring to the wikipedia page and similar. Secondly it is a long and complex thing which tries to cover all possibilities. Advice to just "follow 8601" only takes you so far.
We need to decide (and say) whether to mandate the use of timezone or not. And if not then do we assume "local time" which I agree is a non-portable concept.
I find myself agreeing with Chris that we must directly mandate that all times shall be expressed with timezone. As described in the w3c time formats note (http://www.w3.org/TR/NOTE-datetime). This is a useful reference because it is authoritative, concise to our point and freely available.
I am more agnostic about whether that timezone must be UTC or not.. In some ways I agree with Chris that it might be simplest. On the other hand I am really hesitant to over prescribe this kind of thing. I think any software which is ISO8601 "aware" will be able to consume either of the two formats described in the w3c technical note. So its not so important.
It is important to understand that this formatting issue is purely about data exchange, not the way dates are displayed in GUI or even how they are persisted.
Two much bigger challenges are (i) week numbers and (ii) Islamic (and other) calendar systems which are significantly used.
But we'll solve the easy problems first.
My recommended resolution: "All dates and times should be serialized with timezone indication in accordance with the profile of ISO8601 published by W3C at http://www.w3.org/...".
If people want to further constrain this to UTC I'm ok with that but don't have a strong inclination myself.
Bob
On 21 December 2012 12:17, Chris Ford notifications@github.com wrote:
Previously I suggested that if we're using ISO 8601 dates, then we should additionally at the restriction that it should be an ISO 8601 date with a specified timezone. It seems that mention of timezones has been removed from the spec in the latest version.
If we don't have a timezone, then ISO 8601 says that it should be interpreted as "local time", which is not a sound concept when we're talking about distributed system.
In fact, though I did earlier suggest a compromise that we only recommend UTC, could we make things simpler and mandate UTC? Translating between timezones is complexity we should keep out of the API.
— Reply to this email directly or view it on GitHubhttps://github.com/facilityregistry/fred-api/issues/32.
ctford
mberg
Previously I suggested that if we're using ISO 8601 dates, then we should additionally at the restriction that it should be an ISO 8601 date with a specified timezone. It seems that mention of timezones has been removed from the spec in the latest version.
If we don't have a timezone, then ISO 8601 says that it should be interpreted as "local time", which is not a sound concept when we're talking about distributed system.
In fact, though I did earlier suggest a compromise that we only recommend UTC, could we make things simpler and mandate UTC? Translating between timezones is complexity we should keep out of the API.