Datetime data type missing timezone and precision

[msporny]

The current datetime data type in the specification does not mention timezone or second vs. millisecond precision. This is important for representations to specify. We need a PR to address these shortcomings in the current data model.

[shigeya]

The current specification states that all three representations (JSON, JSON-LD, and CBOR) treat datetime data type as a string.

I propose the following logic: If the parser keeps a deserialized datetime typed string as-is internally and uses the string for serialization, there will be no loss, no issues from a digital signing point of view. If some internal logic next to the abstract data model wants to parse the string, it can parse just for internal logic purposes.

I checked the XML schema spec to be sure.
In XMLdateTime the second fragment is expressed as the following regexp:

[61] secondFrag ::= ([0-5] digit) ('.' digit+)?

Thus, (of course) it is also valid from a lexical representation point of view.

[msporny]

The current specification states that all three representations (JSON, JSON-LD, and CBOR) treat datetime data type as a string.

CBOR-LD does not do this, and instead stores the value as seconds since the Unix epoch (if it can), or a string otherwise.

I'm having a hard time understanding how to translate your proposal into spec text -- @shigeya, could you please provide concrete specification text we could discuss? That might be easier to discuss.

[shigeya]

CBOR-LD does not do this, and instead stores the value as seconds since the Unix epoch (if it can), or a string otherwise.

Okay, now I understand the actual pain point.

I think the spec may have a reasonable constraint to the datetime data type string to avoid the issue. Staying with a similar spec as CBOR-LD seems reasonable, at this moment.

I'm having a hard time understanding how to translate your proposal into spec text -- @shigeya, could you please provide concrete specification text we could discuss? That might be easier to discuss.

I see. I will write an actual spec text after I understand the issue with timezone in a similar way.

[msporny]

This issue will be closed once PR #509 is merged.