Open advorako opened 9 months ago
I think I'd be open to accepting a PR, if you think you could provide one? I agree that it is an edge case, but if special handling would help and would not break main use case, that sounds like a reasonable improvement to me.
In absence of fix, even PR for reproduction would be useful.
Marking test-needed
to indicate we'd need JAva 8 module - only test, outside of Avro module (since this module cannot have dep to Avro module, or vice versa).
Encountered while debugging through a project making use of this for Avro serialization/deserialization:
For an object containing a java.time.Instant with associated Avro schema field of "type" : [ "null", { "type" : "string", "java-class" : "java.time.Instant"} ] ...
InstantDeserializer._fromString() is used to try and parse these numeric timestamp strings, but its _countPeriods() helper method does not account for the possible leading '-' character https://github.com/FasterXML/jackson-modules-java8/blob/2.16/datetime/src/main/java/com/fasterxml/jackson/datatype/jsr310/deser/InstantDeserializer.java#L369-L384
This causes _fromString() to skip over the parsing method that would work in this situation ... https://github.com/FasterXML/jackson-modules-java8/blob/2.16/datetime/src/main/java/com/fasterxml/jackson/datatype/jsr310/deser/InstantDeserializer.java#L409-L410 ... and instead fall through into DateTimeFormatter, which cannot handle this type of string and throws a DateTimeParseException https://github.com/FasterXML/jackson-modules-java8/blob/2.16/datetime/src/main/java/com/fasterxml/jackson/datatype/jsr310/deser/InstantDeserializer.java#L433
Example code:
Output:
I realize this example may be somewhat of an edge case (if not an outdated, deprecated, and/or ill-advised one), given the documentation's current directions towards the use of AvroJavaTimeModule and a schema using numeric data types for java time classes (which does work), but figured this might be worth logging just in case there might be other means of encountering this problem.
For whatever it may be worth, configuring WRITE_DATES_AS_TIMESTAMPS=false appears to provide a workaround (for newly-serialized data, at least), should one's Avro schema not be easily changeable.