java - Timezones and JSON reading with jersey -
on page user enters birthday. model saves date javascript date. in request date gets converted utc the timezone offset of date given. on server side jersey reads date , adds the current timezoneoffset.
so of writing post happens (server in cet):
user enters:
01/03/1967
client transfers:
json.stringify(new date(1967,2,1)) "1967-02-28t23:00:00.000z"
server adds 1 hour, , gets correctly 01/03/1967
.
but if user enters
01/04/1967
client transfers:
json.stringify(new date(1967,3,1)) "1967-03-31t22:00:00.000z"
server adds 1 hour, , gets incorrectly 31/03/1967
. when dst gets involved in summer, server add 2 hours , date correct again.
i transferring date string (not date object, user entered).
does else have issue? how solve discrepancy?
i not getting deterministic behaviour out of json.stringify, why uses 2 hours offset , why 1 hour.
for example see following dates:
json.stringify(new date(1981,5,1)) ""1981-05-31t22:00:00.000z"" json.stringify(new date(1980,5,1)) ""1980-05-31t23:00:00.000z""
you have choosen wrong model handling input. start plain date (without time , without timezone). should keep structure. means converting input javascript-date (including time , timezone) not okay introduces problems observe.
unfortunately javascript in built-in version not offer plain date data type. but can @ least convert user input string iso-8601-format, namely: yyyy-mm-dd
then send string via json , on server side can parse ever type wants (here again recommend use plain date model java.time.localdate
in java 8 or org.joda.time.localdate
or similar). if choose java.util.gregoriancalendar
timezone problems should go away because date not changed supplemented (unnecessary) time , timezone informations of server.
note: if jersey still reqires full date-time-zone-input produced json can try add suitable time part (for example midnight) , suitable time zone part manually string serves json-input.
Comments
Post a Comment