Reasoning behind whole-seconds precision for datetime?

[vdods]

I'd like to know the reasoning behind choosing whole-seconds precision instead of e.g. milliseconds precision. From the standpoint of DID doc metadata, it does get in the way of basic guarantees like strict monotonicity of DID update timestamps, as well as ability to query a unique DID document by versionTime.

I see this came up here -- #361 (comment) -- but didn't see any justification.

What have other people used as workarounds here, if at all? My own approach was to define some parallel timestamp fields (e.g. "createdMilliseconds" to parallel "created") and record the milliseconds-precision timestamps that way, in addition to the seconds-precision existing fields. Not ideal, but at least the data is there.

Relevant links:

• Specify datetime precision for serializations. #509
• Datetime data type missing timezone and precision #498

[msporny]

We were concerned about a few things:

1. XML Datetime allows time precision down to Planck time (the smallest unit of time measurement before the currently known laws of physics break down). Many devices are not capable of storing time at that precision.
2. Some IoT implementations store times in "seconds since the epoch", and perform all time calculations in seconds since the epoch. That is, they can't do "milliseconds since the Epoch".
3. If system A digitally signs a document with time at a very high precision, and system B (which can't operate at such high precision) reads that document and tries to re-create the signature, the signature check will fail.

In order to address these concerns, we had to pick a lowest common denominator and that was "seconds". To be clear, this value only applies to values serialized in the DID Document, not for processes outside of the DID Document. That is, a DID Resolver could still operate at higher time precision, AFAIK.

Does this answer your question, @vdods ?

[swcurran]

At least the 3rd item doesn't make sense to me (and not sure about the other two). First, why is System B "re-creating" the signature vs. verifying it? And if it is verifying it, is it not just verifying what is in the document, and not converting elements of the document into its own representation before verifying the signature. I don't get how this impacts signature.

I do understand that using the attributes after verification may be an issue, but I think that is out of scope of the spec, except in the metadata. And in the metadata, since the format is strictly defined (ISO 8601 format, as I recall), there is little complexity there -- a system that can only handle seconds (is there such a thing?) ignores the milliseconds. So why not allow milliseconds? The restriction on using 8601 also invalidates the argument 2 (can't use seconds since epoch) and 1 since we aren't trying to go beyond milliseconds.

Interestingly, this same issue came up in did:webvh this week -- a DID Controller creating DID versions was doing in under a second so versionTime was coming out the same for different versions.

[vdods]

I also don't quite understand the 3rd item. As far as I can tell, the relevant timestamps are stored as strings (e.g. "2026-03-05T23:26:47.261Z"), and there's nothing in preventing an IoT implementation from parsing this string into a date time structure that, say, tracks the fractional seconds separately. In fact, this is the case for the time Rust crate.

That IoT devices might only be able to produce timestamps with whole-seconds precision is a more reasonable assumption (e.g. a poor, granular system clock). In which case they simply produce a timestamp like "2026-03-05T23:26:47Z".

Is #3 about canonicalization for hashing/signing? Assuming so, wouldn't "2026-03-05T23:26:47.261Z" just be fed into the canonicalizer as a string anyway?

[msporny]

Assuming so, wouldn't "2026-03-05T23:26:47.261Z" just be fed into the canonicalizer as a string anyway?

We don't have control over what implementations will do, and some developers aren't aware that their time library implementations silently drop milliseconds. For example,

Python's time library doesn't support milliseconds: https://docs.python.org/2/library/time.html#time.struct_time doesn't support milliseconds

32-bit systems don't support milliseconds: https://en.wikipedia.org/wiki/Year_2038_problem

Arduino's time library doesn't support milliseconds: https://playground.arduino.cc/Code/Time/

Go and Java only support nanoseconds (and you have to write your own millisecond support, and sometimes developers do the wrong divisor): https://pkg.go.dev/time#Layout

Dealing with time across programming environments and architectures is complex, and we can't presume that developers are going to get it right. We don't know if they'll parse the object into a datetime before the recanonicalize to verify the signature. We don't know if they'll verify the signature successfully and then do calculations based on an accidentally truncated datetime. We don't know if they'll use the the right library on their platform to format the outgoing datetime, or parse the incoming datetime... and when they get any one of those things wrong, there are security vulnerabilities that spring forth from all the complexity over time. The spec attempts to eliminate these class of implementation errors.

If milliseconds are important to some implementations, there is a risk that depending on milliseconds will cause troubling bugs in other parts of the ecosystem (like two DID Document updates within milliseconds of each other). The added risk isn't worth whatever use case needs DID Document accuracy to go down to the millisecond.

I've marked this as discuss for the WG to confirm that this is still the WG's consensus position. Even if the consensus position changes during this iteration of the DID spec, we're only allowed to make non-breaking changes in a v1.1 release (and this would be a breaking change -- because the presumption of time precision will go from 32-bit to 64-bit precision).

Interested in both @swcurran's thoughts and @vdods thoughts on this before taking it in front of the DID WG.

[swcurran]

I'm ambivalent to the change -- it came up with did:webvh in parallel with this issue being raised so I chimed in, but further consideration of that use case suggested the did:webvh need was a bad idea for different reasons.

I'm very surprised that any implementation would de-serialize the signed data and re-serialize it to verify the signature. If you say we shouldn't do this because of that, OK. Like the "don't use integers" issue, I think this is a minimal protection that creates bigger problems, but l'll go with the group.