Evgeniy, I've been looking around and I see what you are talking about with the timezone not being respected. This may be an issue in more than one place.
With regard to the content parser, how are you loading content that it utilizes the content parser so that I can replicate? Thanks. - Jason On Mon, Apr 16, 2018, at 4:18 AM, drf...@drfits.com wrote: > Hello Jason, > > I've added PR for Java 8 with below thoughts, so please check it if it > make sense: > https://github.com/apache/sling-org-apache-sling-jcr-contentparser/pull/1 > I guess code will explain much better than I can :) > > С уважением, > Фицнер Евгений Владимирович / > Best Regards, > Evgeniy Fitsner > > Тел. / Phone : +375 29 5386858 > e-mail: drf...@drfits.com > Skype: drfits > > -----Original Message----- > From: Jason E Bailey <j...@apache.org> > Sent: Friday, April 6, 2018 8:41 PM > To: dev@sling.apache.org > Subject: Re: Java version for sling-org-apache-sling-jcr-contentparser bundle > > So the time appears to have an offset on the original server because > there is a GMT offset of 3 hours that is set by the system. If it's a > date value that is stored in the jcr, I believe it's stored as a number > which is converted to a Calendar and that Calendar object by default is > set to the environments timezone. > > Or to rephrase it, it's not stripping the timezone offset off, it's > showing the same instance in time based on the timezone of the > environment. > > I'd have to test it but I don't think changing the returned Calendar > object to a different timezone will change how the value is stored in > the JCR once it's imported. > > - Jason > > On Fri, Apr 6, 2018, at 12:41 PM, Evgeniy Fitsner wrote: > > 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: dev@sling.apache.org > > 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/b > > > lob/master/src/main/java/org/apache/sling/jcr/contentparser/impl/Par > > > serHelper.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? > > >
