When you send temporary types from Java to other systems, you should be unambiguous in things like time of day and time zone. If the instance is indeed a local date, you do not want to convert it to instant time on a universal timeline by choosing an arbitrary time zone. UTC is arbitrary. This is the default time zone.
March 14, 2016 should mean the same for systems on opposite sides of the globe. ISO8601 exists for this purpose.
I recommend this when sending Java LocalDate to your JS client by encoding it in JSON as a string in ISO8601 format using DateTimeFormatter.ISO_LOCAL_DATE.format(localDate)
and parsing from JSON using LocalDate.parse(text, DateTimeFormatter.ISO_LOCAL_DATE)
.
JavaScript Date
more like the old Java Date
class and similarly named incorrectly. However, JavaScript Date
will successfully parse strings in ISO8601 format, either by construction or using the Date.parse()
function, and will generate Date.toISOString()
Date.toISOString()
using Date.toISOString()
. Just note that JavaScript will interpret the missing time zone (denoting local values โโin Java) as UTC. You can be unambiguous by always using the Zulu time zone when you mean UTC, and assuming that JS clients always send you zoned values.
Or just use JS-Joda.
source share