Representation of date-time

[martin-lindstrom]

I see that AT uses ints to represent the sc and dr fields of a test entry (3.json). In CBOR both ints and strings may be used to represent a date-time, BUT ...

Our schema states very clearly that these fields are strings (with the addition of the format as a date-time):

        "sc": {
          "description": "Date/Time of Sample Collection",
          "type": "string",
          "format": "date-time"
        },
        "dr": {
          "description": "Date/Time of Test Result",
          "type": "string",
          "format": "date-time"
        },

So, in my view this is a violation of the schema, and that date-time:s should be represented as strings. I can see why someone thinks an int should be used, but we have already had this discussion during the schema development, and there were consensus for using string-representations only.

[nodh]

Which file are you referring to, exactly, @martin-lindstrom?
I just can't see it, in https://github.com/eu-digital-green-certificates/dgc-testdata/blob/main/AT/2DCode/raw/3.json#L16 it is

"sc": "2021-02-20T12:34:56Z",
"dr": "2021-02-20T14:56:01Z",

[martin-lindstrom]

Yes, the timestamp in JSON are strings. But the CBOR-encoding of the payload is:

               1B 00000177BF6F9180      # unsigned(1613824496000)
               62                       # text(2)
                  6D61                  # "ma"
               64                       # text(4)
                  31323332              # "1232"
               62                       # text(2)
                  6472                  # "dr"
               1B 00000177BF78CCC8      # unsigned(1613825101000)
               62                       # text(2)

And it seems like milliseconds is used. According to RFC8949 it should be seconds since epoch.

[martin-lindstrom]

@nodh So, AT has one definite bug (using milliseconds instead of seconds), and one potential violation of the schema. I don't know if we should use issues to indicate interop-issues. I think it is a good way.

[martin-lindstrom]

@nodh Another issue for you concerning the timestamp. The elements for sc and dr is not tagged. If, which I strongly advises against, are to use numeric representations for timestamps, you need to tag it (1). See RFC8949.

[nodh]

Thanks a lot for testing our codes and spotting that bug :-)