I'll just come out and say that someone, somewhere, will have something break because of this. Because they wrote something that is very specific to a particular use case.
>From a loading of content perspective, the two changes I made keep the same >instance in time, they just correctly store the offset that was provided. If >someone has written a test or some code that manipulated that date based on >the belief that no offset was recorded, that may be impacted. I feel this is >an edge case enough that I'm good with the changes. There are two areas that are sensitive enough that I'm not going to directly commit without conversation. One is POST handler, where the only format that handles the offset correctly is the ISO-8601 format. Although I don't expect the content loaders to be problematic, this fix would be larger then what I can get to for a while. The other is the default JSON rendering for the GET request. There is no specification in our documents and no tests that check to see how the Date string is supposed to be generated. There is no JSON specification for a Date. The XML version of the data is using ISO-8601. So my assumption on the original development of this is that the JSON was being generated in a way that would be easily consumable by browsers at the time. However the format used is now deprecated. Everyone is moving to the ISO-8601 format or, at the very least, their interpretation of the spec. That one is potentially the biggest problem, because it's the one that's most likely to break something. Potential issues would be something like downstream UI components. It's hard for me to say and I would have to do some testing. - Jason On Mon, Apr 23, 2018, at 3:06 AM, Bertrand Delacretaz wrote: > Hi, > > On Fri, Apr 20, 2018 at 3:07 PM, Jason E Bailey <[email protected]> wrote: > > ...I cam to the same conclusion about the Content Loader, I'll make the bug > > and fix for that either today or > > tomorrow. For the second point, I will go ahead and make the bug fix, and > > do a pull request so that > > we can get additional input on it.... > > I haven't looked at the details so far - can you do that while staying > fully backwards compatible, and do we have tests that demonstrate > that? > > I'm asking because incompatibilities in this area could lead to hard > to troubleshoot issues. > > -Bertrand
