Hi Jason,
I’m using value with time-zone offset.
Let me show my use-case:
within JSON file with mocked data for the load I have time field : "birthday":
"Wed Dec 06 2017 00:00:00 GMT+0300" (that’s how it’s stored in OAK)
Timezone offset on my test environment is GMT+0000
If I’ll use method like: Calendar birthday = tryParseCalendar("Wed Dec 06 2017
00:00:00 GMT+0300");
The birthday will have Calendar value: "Tue Dec 05 2017 21:00:00 GMT+0000"
because timezone offset was erased during transformation (from GMT+0300 on
GMT+0000) but I’m expecting to obtain the value which was initially put "Wed
Dec 06 2017 00:00:00 GMT+0300"
From: Jason E Bailey
Sent: Friday, April 6, 2018 7:06 PM
To: [email protected]
Subject: Re: Java version for sling-org-apache-sling-jcr-contentparser bundle
Hi Evgeniy,
If I understand what you're saying correctly, you have a time format that you
are using that doesn't specify a timezone and that is causing a problem with
transferring a date between two different environments that are set to two
different timezones.
Is that a correct?
- Jason
On Fri, Apr 6, 2018, at 5:58 AM, Evgeniy Fitsner wrote:
>
> Dear All,
>
> Not sure who can clarify but I’m faced with issue within this module
> when trying to load dates in format different from ISO-8601: in this
> case I have to specify time-zone manually for returned Calendar object
> every time if stored date has different from my test machine time-zone
> Method:
> https://github.com/apache/sling-org-apache-sling-jcr-contentparser/blob/master/src/main/java/org/apache/sling/jcr/contentparser/impl/ParserHelper.java#L69-L89
>
> So my question: on which java version this module have to be executed?
>
> Because if on Java 8 and above this code can be updated just to return
> correct time-zone w/o additional libraries. Otherwise smth like Joda-
> Time could help if java version prior to 8.
>
> Or this behavior is not an issue and no PR required?
