Align `datetimes` to `dateTimeStamp` values to ensure timezone.

[msporny]

This PR attempts to align the way datetime values are used in this specification with the way they are used in the vc-data-model, namely, ensuring that a dateTimeStamp value is used (which ensures that a timezone is specified when expressing a datetime).

VC v1.0 and v1.1 didn't do this and there were a few instances where systems were creating datetime values that did not include a timezone (and thus were ambiguous because interpreting the time was done using the local timezone... and if a datetime was set in one timezone, there could be a misinterpretation of the datetime value when interpreted in another timezone).

---

Preview | Diff

[brianorwhatever]

Didn't VCDM 1 also specify that the milliseconds couldn't be included as it adds a tracking vector? Is that still the case or did I make this up entirely?

[msporny]

Didn't VCDM 1 also specify that the milliseconds couldn't be included as it adds a tracking vector? Is that still the case or did I make this up entirely?

I vaguely remember something saying that somewhere :) -- so, either it's a shared delusion, or the text exists/existed somewhere. The signature (if it's not an unlinkable one) is more of a tracking vector, so I don't think this is a concern.

We did say that second precision was preferred because it allows good compression in CBOR-LD. The second you add fractions of a second, your byte storage requirements go up a bit... but again, we don't want to prevent people from being able to specify fractions of a second.

IOW, I think we're ok here.

[msporny]

Normative, multiple reviews, no changes requested, no objections, merging.