You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Instant::toISOString() / ZonedDateTime::toISOString returns value that is not RFC 3339 compliant, because it will omit seconds, when its value is zero.
This is causing portability issues, for example, such value is not accepted by java.time.Instant.parse.
I'm surprised to see that the behaviour is different for LocalDateTime and LocalTime: sandbox.
This is probably the source of confusion when I first implemented ZonedDateTime::__toString(), where I just concatenated the output of the LocalDateTime with the timezone.
I'll work on a fix, however this will target version 0.8.0 as this is technically a BC break.
What about parsing, should we force seconds as well? I'm leaning towards yes.
What about parsing, should we force seconds as well?
Java allows missing seconds when parsing ZonedDateTime, LocalDateTime and LocalTime. The missing seconds are allowed by ISO 8601. You also have the problem, that you would be unable to parse string that were generated by brick/date-time < 0.8. So overall I think it's better to keep the parser unchanged.
Instant::toISOString()
/ZonedDateTime::toISOString
returns value that is not RFC 3339 compliant, because it will omit seconds, when its value is zero.This is causing portability issues, for example, such value is not accepted by
java.time.Instant.parse
.Java sandbox
RFC 3339 format description
The text was updated successfully, but these errors were encountered: