Clarify timestamp percision in the spec

[Gozala]

Recently I noticed that spec refers to timestamps without mentioning precision.

spec/README.md

Lines 350 to 351 in 692e8aa

	| `nbf` | `Number` | Not Before UTC Unix Timestamp (valid from) | No |
	| `exp` | `Number \| null` | Expiration UTC Unix Timestamp (valid until) | Yes |

Implementations on the other hand seem to use seconds based precision and encode as such in JWT as well.

I think spec should clarify what precision supposed to be used.

[expede]

It should be the same as in JWT, because these are JWT fields. I agree that we should clarify that in the spec, though 💯

[expede]

From the RFC 7519 (JWT):

NumericDate
A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds. This is equivalent to the IEEE Std 1003 2013 Edition [POSIX.1] definition "Seconds Since the Epoch", which each day is accounted for by exactly 86400 seconds, other than that non-integer values can be represented. See RFC 3339[RFC3339] for details regarding date/times in general and UTC in particular.

Most of this was already clarified in 0.10 (this Issue didn't get auto-closed I guess), but it was raised earlier today that the wording above "non-integer values can be represented" is ambiguous. I agree — I think wjhat they're trying to say is that JSON can't enforce integers by itself. I'm going to clarify that UCAN only accepts ints in the spec.