About your timestamp remarks, the current Avro JSON encoding specification makes JSON:
- not deserializable without the schema as described in "JSON Encoding"[1] part. *"Note that the original schema is still required to correctly process JSON-encoded data."* - not easily human readable partially due to logical type serialisation[1] *"A logical type is always serialized using its underlying Avro type so that values are encoded in exactly the same way as the equivalent Avro type that does not have a logicalType attribute."* So, the interoperability problem you mentioned is not about timestamp but all fields based on long type because they are stored in memory on 64-bits signed integer. As I interpret the RFC 8259 Section 6 [2] BNF grammar, number limit and precision are not limited. So Avro long type does not break the RFC. But as suggested some implementation limited to IEEE 754 ranges to express integers may be wrong. [1] https://avro.apache.org/docs/1.12.0/specification <https://avro.apache.org/docs/1.12.0/specification/#aliases> [2] https://www.rfc-editor.org/rfc/rfc8259#section-6 Regards Le mer. 8 janv. 2025 à 14:54, Clemens Vasters <cleme...@microsoft.com.invalid> a écrit : > I agree with you proposal staying within the range. However, you propose > this to align with the nanosecond timestamps and those are broken for JSON. > > Your proposal called that to my attention. > > Clemens > > -----Original Message----- > From: glywk <glywk.cont...@gmail.com> > Sent: Wednesday, January 8, 2025 12:15 AM > To: dev@avro.apache.org > Subject: Re: Add support of time logical type with nanoseconds precision > > [Sie erhalten nicht häufig E-Mails von glywk.cont...@gmail.com. Weitere > Informationen, warum dies wichtig ist, finden Sie unter > https://aka.ms/LearnAboutSenderIdentification ] > > Hi, > > Your analysis is interesting but about timestamp. My proposal is about > adding nanoseconds support on time logical type. As described in AVRO-4043 > [1], the maximum value of time is 8.64E13. This value doesn't exceeded the > upper range value 2^53-1 recommended for common interoperability with IEEE > 754 floating point representation. > > [1] https://issues.apache.org/jira/browse/AVRO-4043 > > Regards >
