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
Feedback on Dates and Times in Section 11 #22
Comments
Matt, thank you very much for the detailed feedback. |
I'll generally just agree with Matt here, but would add the following:
This text assumes that all date values exchanged by a REST API are defined by a point in time. This assumption is incorrect and does not hold water in the real world. For instance, one might want to express this information in an API:
This is a datetime value, that would be expressed by the ISO8601 standard as You may also encounter time-only situations like
Again, there is no reference to a point in time, and this should be interpreted as time local to the store. This documentation should explicitly state that absent an offset values shall be interpreted as local time (which may vary based on the context of the problem domain). While ISO8601 and ECMAScript already say this, most people won't go look it up, so if this is best practice documentation, best to put it in. It should also be noted that these formats should only be used if you mean local time. If you mean time that represents a point on the global timeline, ISO8601 with offset should almost universally be used. On that note, I will echo that Happy to think harder about the local time documentation and make a pull if you would like one. |
Yes, I'll agree with Maggie's statements (thank you). The On the Black Friday example, I suppose that is indeed a valid value - and one might get it by using a .NET
Does that make sense? |
@garethj-msft - No problem, glad to help. I'm going to ask some of the other @mspnp guys to take a look at the other parts of the guidelines also. Date/time just happens to be my thing. 😄 |
Please review the following constructive criticism with regard to the date and time guidelines in section 11.
Iso8601Literal
is poorly definedZ
or a numeric offset+/-HH:MM
so that they represent a distinct point in time:"2016-07-16T08:23:45Z"
is a specific point in Coordinated Universal Time (UTC)."2016-07-16T01:23:45-07:00"
is the same point in time with a particular time zone offset."2016-07-16T01:23:45"
is not a specific point in time. It could be interpreted differently depending on time zones. While this is type of data may be useful within an application, it has very little meaning in an API and should generally be discouraged as an interchange format."2016-07-16"
is a valid date. Date-only values should always be passed like this."2016-07-16T00:00:00Z"
is not a date. It's a date-time at midnight UTC. The equivalent date value may be quite different when adjusted to the local time zone. This is a commonly encountered anti-pattern, and should be actively discouraged."2016-07-16T00:00:00"
is also not a date. It's a date-time at midnight local time. The main problem here is that not every local date has a midnight (due to daylight saving time spring-forward gaps). For example,"2016-10-16T00:00:00"
does not exist in most of Brazil. Given this value, and this time zone context, some implementations may skip forward to 1:00, some may skip backward to 23:00 the prior day, and some may throw an exception.To address all of these, the guidance should recommend using the
date-time
andfull-date
formats defined in RFC 3339 § 5.6.StructuredDateLiteral
is not good adviceDateKind
value codes appears to be invented here. I know of no JSON library that will create or read value in this split two-state form. You would have to create your own intermediate objects, then either have a long case-statement to handle all the different kinds, or limit yourself to one particular kind. Indeed, the guidance talks about how different clients would need to understand the kind of the server. This requirement defeats the purpose of having an interchange format to begin with. In other words, it's no more helpful to have akind
property that tells you what format to expect in thevalue
property than it would be to describe the custom format in the API's documentation."O"
format is being used for OLE Automation Dates - this format uses an ambiguous local time scale, while most of the others use UTC. Also, some implementations base it from 1900-01-01 or 1899-12-31, instead of 1899-12-30, and there is extra work to account for negative values. This is something that should be only handled directly when interfacing to/from OLE values - such as by callingDateTime.FromOADate
orDateTime.ToOADate
in .NET. The OADate values themselves should never be put into a web API."X"
format honors the Excel 1900 leap year bug - really? This should never leak out of Excel. Putting it in an API would be a horrible thing to do.Misc other items
{ "interval" : "2007-03-01T13:00:00Z/2008-05-11T15:30:00Z" }
is less commonly used than{ "start" : "2007-03-01T13:00:00Z", "end" : "2008-05-11T15:30:00Z" }
. Though either are technically acceptable, the latter is usually prefered because it's easier to work with.Thanks.
The text was updated successfully, but these errors were encountered: