hello jason. yes, this makes sense.
stefan >-----Original Message----- >From: Jason E Bailey [mailto:j...@apache.org] >Sent: Sunday, May 6, 2018 7:21 PM >To: dev@sling.apache.org >Subject: Re: [Discussion] Date handling inconsistencies - resend > >I've been giving it a lot of thought and I think the appropriate choice is >to have it default to ISO-8601 formatting while providing an option to >"enable support for the deprecated ECMA formatting" > >If we don't use ISO-8601 by default we're just delaying issues until we do. >I think it's better to just go ahead and do it while still allowing people >the option to get the older format while stating that support in a way to >imply it will go away at some point. > >- Jason > >On Thu, May 3, 2018, at 3:35 AM, Stefan Seifert wrote: >> 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:j...@apache.org] >> >Sent: Monday, April 23, 2018 8:37 PM >> >To: dev@sling.apache.org >> >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 >> >> >> > >>
