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
<santiago.pimen...@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.pimen...@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.pimen...@netcentric.biz | www.netcentric.es
