Provide a bundle for JSR 310 Date & Time API

[EugenCepoi]

This jsr is not provided as a maven dep. The best solution would be to provide this new bundle as a separate project in order to support older java versions.

[sooraj20890]

so whats the deal with this ? is there a java 8 time bundle for gensonbuilder ? or do i need to create my own custom serializers ?

[EugenCepoi]

No there isn't one, you would have to implement your own converters for these types. If you wanted to contribute them you are welcome.

[sooraj20890]

I mean lots of projects are converting from jodatime to java 8...shouldnt genson be aware of this ? i am surprised

[EugenCepoi]

I have been working on Genson during my free time and for free. I have less free time now that I am willing to spend on this so this is why there is no such bundle. But again contributions are welcome.

[sooraj20890]

let me get this straight ...so is genson your baby ? are you the creator of genson ?i read something about genson scala...is that something i can use instead of genson ? would it support java 8 time ?

[EugenCepoi]

Yes I'm Gensons author (and the differnet bundles and Genson Scala). No it will not. The Scala version of Genson ads support for the scala types and a few other things but doesn't come with java 8.
Honestly if you need this feature for your work I think you can take a look at how I implemented the joda time converters and do something similar for java 8. I could even guide/help a bit on that, I just can't invest as much time anymore.

[sooraj20890]

okay sure thing..can i be your contributor for that ?

[EugenCepoi]

Yeah sure, just to make sure you understand it, contributor here means that basically you will implement the feature and open a pull request with your changes. Or a simpler approach could be to just create your own repo on github for your java 8 bundle.

In this package you can see most of the joda time specific code, I suspect the code for the java 8 bundle might look similar as the data time JSR is highly based on joda time.

If you have questions on how to implement something etc you can use Genson chat room here.

[sooraj20890]

okay..thanks

[nicky9door]

So I finally got around to implementing this here. I created a module called genson-java-datetime which is targeted at 1.8 and contains all the relevant code. I still need to add javadoc and a readme but it seems to handle most of the common Date & Time types.

I took some ideas from how the Jackson library handles datetime objects and also had to make some adjustments to account for differences between JodaTime and JSR310:

• Jodatime will set defaults for fields that aren't parsed by the formatter. For example, using a formatter of ('yyyy') and a value of '2010' to parse a DateTime will generate date time equal to 2010-01-01 00:00:00. Trying to parse a ZonedDateTime in JSR310 in this manner will cause an error by default. To overcome this, I modify any DateTimeFormatter objects used by the bundle into an instance that has parsing defaults set and use this modified formatter to perform all formatting/parsing operations

• JSR310 operates down to the nanosecond level. I therefore added options to select whether to use millis or nanos by default. This can also be overridden at the property level using a new annotation @JsonTimestampFormat. The default is to use milliseconds

• I mostly kept interoperability with @JsonDateFormat. The main difference is that asTimeInMillis is treated as 'use timestamp' and the actual timestamp format used (millis or nanos) will depend on the option configured in the bundle or @JsonTimestampFormat annotation

• I added a bundle option to set the default ZoneId to use for parsing/formatting (when missing from the actual formatting pattern). This can also be overridden at the property level using a new annotation @JsonZoneId. The default ZoneId is ZoneId.systemDefault()

• Bundle can be configured to set the DateTimeFormatter to use for each temporal type

Timestamps

Epoch

The following will be ser/deser into timestamps consisting of either epoch millis or epoch nanos (depending on configured timestamp format):

• Instant
• ZonedDateTime
• OffsetDateTime
• LocalDateTime (using the ZoneId configured in bundle or @JsonZoneId annotation)

LocalDate

LocalDate will be ser/deser into a timestamp containing the number of days from epoch

LocalTime

LocalTime will be ser/deser into a timestamp containing the number of millis or nanos into the day (depending on configured timestamp format);

Array Timestamp

For the remaining types, I decided to follow the approach used by Jackson where the timestamp is an array containing the properties of the TemporalAccessor:

• Period -> [ years, months, days]
• Duration -> [seconds, nanos]
• Year -> [year]
• YearMonth -> [year, month]
• MonthDay -> [month, day]
• OffsetDate -> [hour, minute, second, nanoSecond, offsetSeconds]

[sooraj20890]

no...i am here first..you cant get integrated into actual genson..may be you can advertise your package independently

[nicky9door]

@sooraj20890 I have no problem with that. The code is already packaged as a separate maven module so it would just be a matter of changing the groupId and package names.

[EugenCepoi]

@sooraj20890 I think it might be more interesting for you to reuse what he already implemented instead of redoing all this work. Having done that in the past, it actually takes some time to get things right. If what you want is to contribute to the project there are plenty of other open issues that are not addressed yet.

@nicky9door sweet, this looks really nice! If you feel like to do the extra remaining work of opening a PR and adding the finishing touches that would be great, I'll do the PR review then. That way we could publish the bundle with the rest of the code and enable others to use it. Of course you are free to publish (or not to) the bundle on your own if you don't want to make it part of Genson.

A few questions:

• As the rest of the modules are built against java 7, were you able to import the entire project in say intellij without having jdk conflicts? In the past I've experimented with having mixed modules like this but compilation wasn't playing nicely. An option could be to compile the entire project against java 8.
• What advantage was there in using an array to represent the remaining date like types instead of using an object with key value pairs (outside performance)?

Nice work!

[nicky9door]

@EugenCepoi I'm cool with submitting a PR once I get the API finalized and some basic documentation written up. Hopefully it will be done within the next couple days

As far as mixed modules go, I left the genson pom.xml at 1.7 and just set the genson-java-datetime module to 1.8. My intellij is configured to use a Java 8 JDK but I think the compiler respects the target property. Another option is to configure the executable property in the maven compiler plugin to point to a Java 8 version of javac. I'll try to play around with some compilation configurations when I get a chance

I got the idea of using an array for the remaining types from looking at how it was implemented in the Jackson library. The idea of using an object never really crossed my mind but it's certainly possible. I might take the approach I used for the DateTimeFormatters where the timestamp format can be configured for each type

[EugenCepoi]

Ok cool, that would be great, there is no rush though.

On a side note, when you plan on contributing to some open source project I think it could be a good idea to open a ticket for (in the github sense) or update an existing issue, so people know that someone is working on it. Mostly to avoid the current situation where someone else also started working on the same issue. Thanks! :)