Sticking to ISO-8601 tends to work well for strings, but even that standard allows for several other formats. I agree that using epoch millis or even regular unix timestamps tends to be the easiest way to handle it in JSON.
On 26 June 2017 at 07:49, Peter Kriens <[email protected]> wrote: > The problem with LocalDate and LocalTime is that you immediately run into > encoding the date. As a string? Which format? As a long? What timezone? > Though there are standards non relate to JSON. > > In my experience, time is best passed as a long epoch time. For local date > en time you should best use strings and handle the conversion in your code. > > If you still want to do it then the DTOs must be adapted to provide a way > to control the JSONifying of these types. Currently this is done via the > bnd converter. So you could add this to the bnd Converter class, then the > next release will support it. However, since there is no JSON standard for > dates you will have to make a choice what encoding to use and I am not sure > that will be easy since there is so much choice. > > Kind regards, > > Peter Kriens > > > On 26 Jun 2017, at 14:32, vijayakumar mohan < > [email protected]> wrote: > > > > Hi, > > I would like to extend the date handling capability in OSGI enroute > framework to support the new java.time packages. > > For example , if i want to support DTOs with LocalDate and LocalTime how > do i go about doing it?. > > > > Thanks in advance, > > Vijayakumar > > _______________________________________________ > > OSGi Developer Mail List > > [email protected] > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- Matt Sicker <[email protected]>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
