Hi, On 15 January 2015 at 08:13, Davide Giannella <dav...@apache.org> wrote: > On 14/01/2015 14:50, Bertrand Delacretaz wrote: >> On Wed, Jan 14, 2015 at 3:40 PM, Santiago García Pimentel >>> ... I would actually like to keep using this behavior since it simplifies >>> things >>> for me, but I want to put it on the table since I would not want for this >>> behavior to change unexpectedly in a future release.... >> Considering that no one asked for that since 2008 when we created >> Sling, the risk of it changing unexpectedly or subtly in the future is >> certainly not zero. >> >> However, if you're willing to supply a patch including the required >> changes to SlingDateValuesTest to validate your changes, this looks >> like a reasonable improvement to me. Assuming Oak supports preserving >> the timezone on stored dates, but you can check that by running the >> launchpad/testing build with -Dsling.run.modes=oak >> > In Oak behind the scene we store every date as String in ISO8601 format.
ISO8601 covers time zone offset eg +05:00, but doesn't cover time zone eg CST, (see Wikipedia for explanation) which is required to deal with calculations and transitions near daylight saving changes. (repeating event sequences). In the past I extended/encapsulated the Calendar object, and provided a custom serialisation to deal it into 2 properties. That may not be relevant to the use case in question. Best Regards Ian > > https://issues.apache.org/jira/browse/OAK-1111 > > This is converted in and out from Calendar to adhere the JCR API. I > think that if you're using oak as a backend and using the jcr api you > store the Calendar that includes the correct timezone it should work. > > HTH > Davide > >
