On 15/01/15 09:47, Ian Boston wrote:
Hi,
On 15 January 2015 at 08:13, Davide Giannella <[email protected]> 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
Thanks Ian.
yes I have to deal with daylight savings, but I calculate the correct
offset before saving the property. So I have no need for this.
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
--
*Santiago García Pimentel* | Software Engineer
Netcentric Ibérica SL
Av. Diagonal 123 -8ª
08005 Barcelona
España
Skype: santiago.garciapimentel
[email protected] | www.netcentric.es
