Use millisecond semantic to match automerge-core

[lightsprint09]

This changes timestamp to use milliseconds as documented here and discussed in #139 . Date is now used to represent a timestamp, to prevent mistakes when encoding/decoding. Converting Date to FFI representation is now in a single file

[ept]

Hold on a minute, is it actually correct that automerge-core uses milliseconds resolution? I thought it was using seconds.

[ept]

Oh sorry, we're talking about timestamps that appear in the document data. Yes, for those we use milliseconds. I thought we were talking about the change timestamp, which I believe uses integer seconds.

[heckj]

Note for release: we'll want to make sure to broadcast loudly that this changed - if anyone already has Date representations in their Automerge docs created, this will cause all of their Date values to be "broken", since we were representing them differently.

[alexjg]

I also missed this so I think having some kind of concrete interop test would be a good idea, though I'm not sure exactly what that would look like.

[alexjg]

In terms of written documentation the value section of the binary format docs exists but is quite dense.

[heckj]

@alexjg I was thinking exactly the same thing just a few minutes earlier. Especially for the various language implementations, I think it would be a great idea. Maybe even just a document that has one of each of the .scalarValue data blobs within it, with specific values, and an external representation. In practice, and looking through the .scalarValue data types, I think the only one that's subject to "local interpretation" is the timestamp value, but as we advance into more "attributed strings" territory, I think the concept of a common reference document will hold us in good stead, and we can make sure that some level of "marks" or attributes/blocks are equally matched in cross-platform representations.

UPDATE: opened a PR to add an interop exemplar document into Automerge core: https://github.com/automerge/automerge/pull/895

[heckj]

@lightsprint09 I think your rebasing went a bit awry here, GH is complaining about it being "unmergable"

[lightsprint09]

Looks good to me?

[heckj]

[lightsprint09]

hmm ;)

[heckj]

Odd - if you can merge it, go ahead - it's been complaining since you merge back the main branch, but if it's clear for you, awesome.