maybe this would be a sensible first step - although it would be fine to have it by default to ISO-8601 in the future for new applications.
stefan >-----Original Message----- >From: Jason E Bailey [mailto:[email protected]] >Sent: Monday, April 23, 2018 8:37 PM >To: [email protected] >Subject: Re: [Discussion] Date handling inconsistencies - resend > >For the JSON rendering, would a service configuration to enable ISO8601 >date support be sufficient initially? > > >- Jason > >On Mon, Apr 23, 2018, at 12:58 PM, Jason E Bailey wrote: >> 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 >> >
