Use millisecond semantic to match automerge-core #141
Conversation
|
Hold on a minute, is it actually correct that automerge-core uses milliseconds resolution? I thought it was using seconds. |
|
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. |
There was a problem hiding this comment.
Thanks Lucas
Is there any place that we have a unified document with all the various data representations that we could use to verify the assertion that it's in milliseconds with Javascript and/or Rust? I'd really like to get something that's concrete to verify the assertions of representation like this, especially since it was a mistake I made early on and jsut never caught, since I wasn't using this cross-platform - although that's the goal here.
|
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. |
|
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. |
|
In terms of written documentation the value section of the binary format docs exists but is quite dense. |
|
@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.
|
Co-authored-by: Joseph Heck <heckj@mac.com>
…nto miliseconds-timestamp # Conflicts: # Sources/Automerge/ScalarValueRepresentable.swift # Tests/AutomergeTests/TestScalarValueConversions.swift
…automerge-swift into miliseconds-timestamp
|
@lightsprint09 I think your rebasing went a bit awry here, GH is complaining about it being "unmergable" |
|
Looks good to me? |
|
hmm ;) |
|
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. |
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