Closed crystalin closed 4 years ago
That is correct, but the Date
class in Java can't have more precision than milliseconds. The question would be if 2017-01-01T01:01:01.123999999Z
should interpreted as 2017-01-01T01:01:01.123Z
or 2017-01-01T01:01:01.124Z
I don't think it is a big issue at that point. Having 123 is what I've seen in other libraries.
As long as .52 != .052
On Sat, Apr 7, 2018, 7:04 PM Julio Viera notifications@github.com wrote:
That is correct, but the Date class in Java only holds up to milliseconds. The question would be if 2017-01-01T01:01:01.123456789Z should interpreted as 2017-01-01T01:01:01.123Z or 2017-01-01T01:01:01.124Z
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/julman99/gson-fire/issues/40#issuecomment-379505413, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUGIBWmU2b30xujamG2-KEz4KkJovA4ks5tmUXhgaJpZM4TK1Ns .
Hi sir,
When looking at your code, I notice that your RFC3339 Parser (https://github.com/julman99/gson-fire/blob/master/src/main/java/io/gsonfire/util/RFC3339DateFormat.java#L93) is considering the fraction of a second as milliseconds, which is incorrect according to the RFC3339 specs.
It should be a fraction of a second, made of 1 or more digits see (https://tools.ietf.org/html/rfc3339#section-5.6)
this would be a valid rfc3339: 2017-01-01T01:01:01.123456789Z
Alan