Asyncapi date-time vs RFC3339 formats

[TheSadlig]

Allo !

Currently, when a field has "date-time" as its format, it is parsed using time.RFC3339 (it is used in multiple places):

asyncapi-codegen/pkg/codegen/generators/v2/templates/message.tmpl

Line 58 in 931df74

t, err := time.Parse(time.RFC3339, string(bMsg.Payload))

That constant is defined here:
https://pkg.go.dev/time#pkg-constants
as RFC3339 = "2006-01-02T15:04:05Z07:00"

According to the specification, the date-time format
https://www.asyncapi.com/docs/reference/specification/v3.0.0#dataTypeFormat
-> https://www.rfc-editor.org/rfc/rfc3339.html#section-5.6

is defined as:

   time-secfrac    = "." 1*DIGIT
   time-numoffset  = ("+" / "-") time-hour ":" time-minute
   time-offset     = "Z" / time-numoffset

   partial-time    = time-hour ":" time-minute ":" time-second
                     [time-secfrac]
   full-date       = date-fullyear "-" date-month "-" date-mday
   full-time       = partial-time time-offset

   date-time       = full-date "T" full-time

The difference is with the time-secfrac which is not included in that constant.

I see two options to solve that:

• Use time.RFC3339Nano which is defined as RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00"
  • Weirdly, it accepts more that one digit, which does not seem to be RFC3339-compliant.
  • I am unsure as to whether this could cause any issue
• Redefine the constant as RFC3339 = "2006-01-02T15:04:05.9Z07:00" within generated code to ensure compliance

Please let me know what are your thoughts on this

Thanks,
TheSadlig

[lerenn]

I would go for the simplest one, so RFC3339Nano one, and add a test to ensure that it is correctly parsed in case that there is a breaking change in the future.

However, I'm not against the second solution :)