You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Santiago García Pimentel <sa...@netcentric.biz> on 2015/01/12 14:15:25 UTC
storing dates with timezones in Sling
Hello,
In a current project I have the need to store dates with specific
timezones. The current behavior stores all given dates in the server
local time, even when a timezone is specified. (see
https://issues.apache.org/jira/browse/SLING-4258 ).
Is there a way I can accomplish this? If no, how could this be changed
without breaking backward compatibility?
Greetings
--
*Santiago García Pimentel* | Software Engineer
Netcentric Ibérica SL
Av. Diagonal 123 -8ª
08005 Barcelona
España
Skype: santiago.garciapimentel
santiago.pimentel@netcentric.biz | www.netcentric.es
Re: storing dates with timezones in Sling
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Jan 15, 2015 at 4:08 PM, Santiago García Pimentel
<sa...@netcentric.biz> wrote:
> I have created a Pull request regarding this topic...
Looks good but as I have commented in SLING-4258 JsonObjectCreator is
missing tests in our current codebase - I'm working on creating those,
will let you know there when it's ready and you can then adapt those
unit tests to your changes.
-Bertrand
Re: storing dates with timezones in Sling
Posted by Santiago García Pimentel <sa...@netcentric.biz>.
I have created a Pull request regarding this topic
https://github.com/apache/sling/pull/54
-make sure that the json representation of dates keeps the stored timezone
-add tests to SlingDateValuesTest for some dates with different timezones.
WDYT?
Greetings
On 12/01/15 14:15, Santiago García Pimentel wrote:
> Hello,
>
> In a current project I have the need to store dates with specific
> timezones. The current behavior stores all given dates in the server
> local time, even when a timezone is specified. (see
> https://issues.apache.org/jira/browse/SLING-4258 ).
>
> Is there a way I can accomplish this? If no, how could this be changed
> without breaking backward compatibility?
>
> Greetings
> --
> *Santiago García Pimentel* | Software Engineer
> Netcentric Ibérica SL
> Av. Diagonal 123 -8ª
> 08005 Barcelona
> España
> Skype: santiago.garciapimentel
> santiago.pimentel@netcentric.biz | www.netcentric.es
--
*Santiago García Pimentel* | Software Engineer
Netcentric Ibérica SL
Av. Diagonal 123 -8ª
08005 Barcelona
España
Skype: santiago.garciapimentel
santiago.pimentel@netcentric.biz | www.netcentric.es
Re: storing dates with timezones in Sling
Posted by Santiago García Pimentel <sa...@netcentric.biz>.
On 15/01/15 09:47, Ian Boston wrote:
> Hi,
>
> On 15 January 2015 at 08:13, Davide Giannella <da...@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
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
santiago.pimentel@netcentric.biz | www.netcentric.es
Re: storing dates with timezones in Sling
Posted by Ian Boston <ie...@tfd.co.uk>.
Hi,
On 15 January 2015 at 08:13, Davide Giannella <da...@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
>
>
Re: storing dates with timezones in Sling
Posted by Davide Giannella <da...@apache.org>.
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.
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
Re: storing dates with timezones in Sling
Posted by Bertrand Delacretaz <bd...@apache.org>.
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
-Bertrand
Re: storing dates with timezones in Sling
Posted by Santiago García Pimentel <sa...@netcentric.biz>.
Hi Robert,
On 14/01/15 15:23, Robert Munteanu wrote:
> Hi,
>
> On Wed, Jan 14, 2015 at 3:49 PM, Santiago García Pimentel
> <sa...@netcentric.biz> wrote:
>> TL;DR: Using the ISO8601 format for dates keeps the original timezone
>> instead of shifting it to the local timezone, unlike the rest of the
>> supported formats.
>>
>> On 13/01/15 17:06, Konrad Windszus wrote:
>>> Maybe you can explain a bit more in detail why you want to keep the
>>> original timezone?
>>
>> Sure.
>> We have to store details about certain corporate events.These events could
>> be anywhere in the world. Also, these events of course have date and time
>> assigned to them.
>>
>> We need to to several things with the dates:
>> 1- show them in local time
>> 2- sort them
>> 2- calculate & show the remaining time for the event to start (a
>> countdown).
>>
>> If we had only requirement 1 we could just ignore the timezone and just show
>> the time, but the other two complicates the things. the countdown should
>> reach zero for every visitor at the same time no matter their timezone. So
>> we cannot ignore the timezone of the event.
> Would it help if you stored the timezone separately for each event?
>
> Robert
Yes, I commented that just in the next paragraph. What I wanted to point
now it that there are some discrepancies in the way timezones are
managed in Sling.
-Docs says time is always in the local server timezone
-Providing an ISO8601 date string does not behaves as the doc says, but
keeps the original timezone
-The xml and json servlets display the date different if you happened to
store it using the ISO8601 format.
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.
>
>> I am a bit surprised that requirements involving timezones had not been
>> discussed previously. I know I could use more than one property for each
>> case, but I would definitively prefer that the repository to respect the
>> timezone I provide.
>>
>> Now the interesting thing:
>>
>> I have been debugging the Post Servlet and found that dates are created from
>> a java.util.Date and then a Calendar object, loosing the timezone in the
>> process. Except for the ISO8601 case, which uses a jackrabbit class that
>> does respect the timezone.
>>
>> I made some test in a Sling instance to check this:
>>
>> curl -F 'date1=2015-01-07T12:00:00.000+04:00' -F 'date1@TypeHint=Date'
>> http://localhost:8080/tmp/testdate
>> then check the result:
>> curl http://localhost:8080/tmp/testdate.json
>> {"jcr:primaryType":"nt:unstructured","date1":"*Wed Jan 07 2015 09:00:00
>> GMT+0100*"}
>> that is how I was told it works, but......
>>
>> curl http://localhost:8080/tmp/testdate.xml
>> <?xml version="1.0" encoding="UTF-8"?><testdate
>> jcr:primaryType="nt:unstructured" date1="*2015-01-07T12:00:00.000+04:00*"
>> ...../>
>>
>> ... so there is my timezone!
>>
>> apparently Sling does support saving the original timezone when using the
>> jackrabbit parser, but I was not getting it right because the json servlet
>> changes the timezone. This is clearly a bug, the xml and json servlets
>> should return the same value for the date.
>>
>> About the timezone. I guess that keeping the original timezone when using
>> the ISO8601 string is actually a bug (undocumented feature to me ;) ), but I
>> think should probably either be kept and specified to we can take advantage
>> of it or fix it so the behavior is the same for all date formats.
>>
>> WDYT?
>>
>> Greetings.
>>
>>
>>
>>> Usually you are only interested in the absolute UTC time (no matter in
>>> which timezone the date is given initially) when it comes to date/time
>>> comparisons/calculations. What do you want to do with the timezone
>>> information?
>>> Do you need that for printing date information i.e. for converting it to a
>>> string (e.g. with the SimpleDateFormat)?
>>> Konrad
>>>
>>>
>>>> Am 12.01.2015 um 14:15 schrieb Santiago García Pimentel
>>>> <sa...@netcentric.biz>:
>>>>
>>>> Hello,
>>>>
>>>> In a current project I have the need to store dates with specific
>>>> timezones. The current behavior stores all given dates in the server local
>>>> time, even when a timezone is specified. (see
>>>> https://issues.apache.org/jira/browse/SLING-4258 ).
>>>>
>>>> Is there a way I can accomplish this? If no, how could this be changed
>>>> without breaking backward compatibility?
>>>>
>>>> Greetings
>>>> --
>>>> *Santiago García Pimentel* | Software Engineer
>>>> Netcentric Ibérica SL
>>>> Av. Diagonal 123 -8ª
>>>> 08005 Barcelona
>>>> España
>>>> Skype: santiago.garciapimentel
>>>> santiago.pimentel@netcentric.biz | www.netcentric.es
>>
>>
>> --
>> *Santiago García Pimentel* | Software Engineer
>> Netcentric Ibérica SL
>> Av. Diagonal 123 -8ª
>> 08005 Barcelona
>> España
>> Skype: santiago.garciapimentel
>> santiago.pimentel@netcentric.biz | www.netcentric.es
--
*Santiago García Pimentel* | Software Engineer
Netcentric Ibérica SL
Av. Diagonal 123 -8ª
08005 Barcelona
España
Skype: santiago.garciapimentel
santiago.pimentel@netcentric.biz | www.netcentric.es
Re: storing dates with timezones in Sling
Posted by Robert Munteanu <ro...@apache.org>.
Hi,
On Wed, Jan 14, 2015 at 3:49 PM, Santiago García Pimentel
<sa...@netcentric.biz> wrote:
> TL;DR: Using the ISO8601 format for dates keeps the original timezone
> instead of shifting it to the local timezone, unlike the rest of the
> supported formats.
>
> On 13/01/15 17:06, Konrad Windszus wrote:
>>
>> Maybe you can explain a bit more in detail why you want to keep the
>> original timezone?
>
>
> Sure.
> We have to store details about certain corporate events.These events could
> be anywhere in the world. Also, these events of course have date and time
> assigned to them.
>
> We need to to several things with the dates:
> 1- show them in local time
> 2- sort them
> 2- calculate & show the remaining time for the event to start (a
> countdown).
>
> If we had only requirement 1 we could just ignore the timezone and just show
> the time, but the other two complicates the things. the countdown should
> reach zero for every visitor at the same time no matter their timezone. So
> we cannot ignore the timezone of the event.
Would it help if you stored the timezone separately for each event?
Robert
>
> I am a bit surprised that requirements involving timezones had not been
> discussed previously. I know I could use more than one property for each
> case, but I would definitively prefer that the repository to respect the
> timezone I provide.
>
> Now the interesting thing:
>
> I have been debugging the Post Servlet and found that dates are created from
> a java.util.Date and then a Calendar object, loosing the timezone in the
> process. Except for the ISO8601 case, which uses a jackrabbit class that
> does respect the timezone.
>
> I made some test in a Sling instance to check this:
>
> curl -F 'date1=2015-01-07T12:00:00.000+04:00' -F 'date1@TypeHint=Date'
> http://localhost:8080/tmp/testdate
> then check the result:
> curl http://localhost:8080/tmp/testdate.json
> {"jcr:primaryType":"nt:unstructured","date1":"*Wed Jan 07 2015 09:00:00
> GMT+0100*"}
> that is how I was told it works, but......
>
> curl http://localhost:8080/tmp/testdate.xml
> <?xml version="1.0" encoding="UTF-8"?><testdate
> jcr:primaryType="nt:unstructured" date1="*2015-01-07T12:00:00.000+04:00*"
> ...../>
>
> ... so there is my timezone!
>
> apparently Sling does support saving the original timezone when using the
> jackrabbit parser, but I was not getting it right because the json servlet
> changes the timezone. This is clearly a bug, the xml and json servlets
> should return the same value for the date.
>
> About the timezone. I guess that keeping the original timezone when using
> the ISO8601 string is actually a bug (undocumented feature to me ;) ), but I
> think should probably either be kept and specified to we can take advantage
> of it or fix it so the behavior is the same for all date formats.
>
> WDYT?
>
> Greetings.
>
>
>
>> Usually you are only interested in the absolute UTC time (no matter in
>> which timezone the date is given initially) when it comes to date/time
>> comparisons/calculations. What do you want to do with the timezone
>> information?
>> Do you need that for printing date information i.e. for converting it to a
>> string (e.g. with the SimpleDateFormat)?
>> Konrad
>>
>>
>>> Am 12.01.2015 um 14:15 schrieb Santiago García Pimentel
>>> <sa...@netcentric.biz>:
>>>
>>> Hello,
>>>
>>> In a current project I have the need to store dates with specific
>>> timezones. The current behavior stores all given dates in the server local
>>> time, even when a timezone is specified. (see
>>> https://issues.apache.org/jira/browse/SLING-4258 ).
>>>
>>> Is there a way I can accomplish this? If no, how could this be changed
>>> without breaking backward compatibility?
>>>
>>> Greetings
>>> --
>>> *Santiago García Pimentel* | Software Engineer
>>> Netcentric Ibérica SL
>>> Av. Diagonal 123 -8ª
>>> 08005 Barcelona
>>> España
>>> Skype: santiago.garciapimentel
>>> santiago.pimentel@netcentric.biz | www.netcentric.es
>
>
>
> --
> *Santiago García Pimentel* | Software Engineer
> Netcentric Ibérica SL
> Av. Diagonal 123 -8ª
> 08005 Barcelona
> España
> Skype: santiago.garciapimentel
> santiago.pimentel@netcentric.biz | www.netcentric.es
Re: storing dates with timezones in Sling
Posted by Santiago García Pimentel <sa...@netcentric.biz>.
TL;DR: Using the ISO8601 format for dates keeps the original timezone
instead of shifting it to the local timezone, unlike the rest of the
supported formats.
On 13/01/15 17:06, Konrad Windszus wrote:
> Maybe you can explain a bit more in detail why you want to keep the original timezone?
Sure.
We have to store details about certain corporate events.These events
could be anywhere in the world. Also, these events of course have date
and time assigned to them.
We need to to several things with the dates:
1- show them in local time
2- sort them
2- calculate & show the remaining time for the event to start (a
countdown).
If we had only requirement 1 we could just ignore the timezone and just
show the time, but the other two complicates the things. the countdown
should reach zero for every visitor at the same time no matter their
timezone. So we cannot ignore the timezone of the event.
I am a bit surprised that requirements involving timezones had not been
discussed previously. I know I could use more than one property for each
case, but I would definitively prefer that the repository to respect the
timezone I provide.
Now the interesting thing:
I have been debugging the Post Servlet and found that dates are created
from a java.util.Date and then a Calendar object, loosing the timezone
in the process. Except for the ISO8601 case, which uses a jackrabbit
class that does respect the timezone.
I made some test in a Sling instance to check this:
curl -F 'date1=2015-01-07T12:00:00.000+04:00' -F 'date1@TypeHint=Date'
http://localhost:8080/tmp/testdate
then check the result:
curl http://localhost:8080/tmp/testdate.json
{"jcr:primaryType":"nt:unstructured","date1":"*Wed Jan 07 2015 09:00:00
GMT+0100*"}
that is how I was told it works, but......
curl http://localhost:8080/tmp/testdate.xml
<?xml version="1.0" encoding="UTF-8"?><testdate
jcr:primaryType="nt:unstructured"
date1="*2015-01-07T12:00:00.000+04:00*" ...../>
... so there is my timezone!
apparently Sling does support saving the original timezone when using
the jackrabbit parser, but I was not getting it right because the json
servlet changes the timezone. This is clearly a bug, the xml and json
servlets should return the same value for the date.
About the timezone. I guess that keeping the original timezone when
using the ISO8601 string is actually a bug (undocumented feature to me
;) ), but I think should probably either be kept and specified to we can
take advantage of it or fix it so the behavior is the same for all date
formats.
WDYT?
Greetings.
> Usually you are only interested in the absolute UTC time (no matter in which timezone the date is given initially) when it comes to date/time comparisons/calculations. What do you want to do with the timezone information?
> Do you need that for printing date information i.e. for converting it to a string (e.g. with the SimpleDateFormat)?
> Konrad
>
>
>> Am 12.01.2015 um 14:15 schrieb Santiago García Pimentel <sa...@netcentric.biz>:
>>
>> Hello,
>>
>> In a current project I have the need to store dates with specific timezones. The current behavior stores all given dates in the server local time, even when a timezone is specified. (see https://issues.apache.org/jira/browse/SLING-4258 ).
>>
>> Is there a way I can accomplish this? If no, how could this be changed without breaking backward compatibility?
>>
>> Greetings
>> --
>> *Santiago García Pimentel* | Software Engineer
>> Netcentric Ibérica SL
>> Av. Diagonal 123 -8ª
>> 08005 Barcelona
>> España
>> Skype: santiago.garciapimentel
>> santiago.pimentel@netcentric.biz | www.netcentric.es
--
*Santiago García Pimentel* | Software Engineer
Netcentric Ibérica SL
Av. Diagonal 123 -8ª
08005 Barcelona
España
Skype: santiago.garciapimentel
santiago.pimentel@netcentric.biz | www.netcentric.es
Re: storing dates with timezones in Sling
Posted by Konrad Windszus <ko...@gmx.de>.
Maybe you can explain a bit more in detail why you want to keep the original timezone? Usually you are only interested in the absolute UTC time (no matter in which timezone the date is given initially) when it comes to date/time comparisons/calculations. What do you want to do with the timezone information?
Do you need that for printing date information i.e. for converting it to a string (e.g. with the SimpleDateFormat)?
Konrad
> Am 12.01.2015 um 14:15 schrieb Santiago García Pimentel <sa...@netcentric.biz>:
>
> Hello,
>
> In a current project I have the need to store dates with specific timezones. The current behavior stores all given dates in the server local time, even when a timezone is specified. (see https://issues.apache.org/jira/browse/SLING-4258 ).
>
> Is there a way I can accomplish this? If no, how could this be changed without breaking backward compatibility?
>
> Greetings
> --
> *Santiago García Pimentel* | Software Engineer
> Netcentric Ibérica SL
> Av. Diagonal 123 -8ª
> 08005 Barcelona
> España
> Skype: santiago.garciapimentel
> santiago.pimentel@netcentric.biz | www.netcentric.es
Re: storing dates with timezones in Sling
Posted by Santiago García Pimentel <sa...@netcentric.biz>.
I've updated my pull request to include unit and integration tests to
handle correctly the timezone.
Still, I think this can be improved. Right now Sling only keeps the
original timezone when using the ISO8601 formatter. This seems
counterintuitive to me. I think that if a timezone is provided it should
be kept. Do you agree?
The change would not be very complex, we can parse the offset from the
date string and set it to the DateFormatter before parsing the date.
WDYT'
--
*Santiago García Pimentel* | Software Engineer
Netcentric Ibérica SL
Av. Diagonal 123 -8ª
08005 Barcelona
España
Skype: santiago.garciapimentel
santiago.pimentel@netcentric.biz | www.netcentric.es