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
On Thu, Jan 15, 2015 at 4:08 PM, Santiago García Pimentel
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 r
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 P
On 15/01/15 09:47, Ian Boston wrote:
Hi,
On 15 January 2015 at 08:13, Davide Giannella 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
Hi,
On 15 January 2015 at 08:13, Davide Giannella 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
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 unex
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 on
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
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
Hi,
On Wed, Jan 14, 2015 at 3:49 PM, Santiago García Pimentel
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 ca
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
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
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, h
12 matches
Mail list logo
