search

FasterXML / jackson-modules-java8

Set of support modules for Java 8 datatypes (Optionals, date/time) and features (parameter names)
Apache License 2.0
401 stars 117 forks source link

Probably bug with Instant deserialization #109

Closed AntonKuzValid closed 4 years ago

AntonKuzValid commented 5 years ago

When i deserialize Instant and use DeserializationFeature.READ_DATE_TIMESTAMPS_AS_NANOSECONDS i expect that value - for example (946684800900000000) will deserialize successfully, but only values with point like these (946684800.900000000) work correct. I fixed it and can create pull request

cowtowncoder commented 5 years ago

Ok this took me a while to read through, and I am not 100% sure still... but I think this is not a bug but the way things should work. Looking at README (https://github.com/FasterXML/jackson-modules-java8/tree/master/datetime):

The more ambiguous integer types are read as fractional seconds without a decimal point if 
READ_DATE_TIMESTAMPS_AS_NANOSECONDS is enabled (it is by default), and otherwise
they are read as milliseconds.

which I think indicates that integral number is in seconds, not nano-seconds.

This is not necessarily the optimal behavior, but considering that there is no mechanism for serializing into integer nanoseconds, I am not sure that alternative would be better.

@beamerblvd what do you think?

cowtowncoder commented 4 years ago

As per my comment above, I do not think this is valid as suggested. There may be improvements, but direct change like this does not seem like right way.