Adding milliseconds to wireprotocol

[guiguem]

Updating the documentation of the wire-protocol; the version of dripline (defined in Version.rst) needs to be updated to the right version of dripline during the release process

[laroque]

We need to be very clear about what is required/allowed here. Is the new protocol exactly 3 digits after the decimal? Do we require a decimal and allow any number of digits after? Something else?

This will impact how it gets implemented

[guiguem]

as far as I read from the website linked in the documentation, there should be a "." and then the fractional seconds. since we care about ms, I thought that would make sense to have yyyy-mm-ddThh:mm:ss.XXXZ

I would be happy if we decide another convention.

[guiguem]

To be clearer, I used section 5.6 of https://www.ietf.org/rfc/rfc3339.txt

[wcpettus]

I think Ben's point is that python actually lacks a native way of doing millisecond precision. It's strftime in datetime has a %f option which gives microseconds, but you can't ask for only milliseconds (or only n digits of microsecond precision).

If you give python arbitrary a datetime string with millisecond or microsecond precision, the %f can read it in properly. If you exceed microsecond precision it's going to break again on the read.

So it would be useful to understand how the different languages operate here, whether they have flexibility in output and parsing. I think we can probably largely ignore go because it is planned for retirement?

[nsoblath]

In C++ I should be able to specify a number of digits after the decimal point or not. If not, it leaves it up to the default in std::cout, which is typically 3 or something.

We can officially ignore the golang implementation.

I have notes about how to implement in C++ here: https://github.com/project8/dripline-cpp/issues/4

[laroque]

What's more, python's datetime class seems to want to use microseconds not milliseconds (ie always 6 digits). To be a bit more verbose:

• When decoding a string, python is fine so long as there is a decimal and between 1 and 6 digits after. By default it complains if there is a decimal with no trailing digit or more than 6
• When writing, python naturally wants to fill in 6 digits for the timestamp
• For writing, it would be easy enough to write a utility function that trimmed to 3 digits and returned that and only slightly harder to grep through the code and convert lots of strftime calls to use that function
• For reading we'd similarly need to grep through for strptime calls and either pre-format things or setup some exception handling. Also not too hard but not nothing.

[nsoblath]

The scarab2/develop branch of scarab now has the ability to do sub-second precision timestamps with the standard format. Releasing that will come with Scarab2 because this is a break in the time API. I can make whatever changes are necessary to adapt to the final decision we make for the dripline wire protocol.

Dripline-cpp has also been updated to use the new scarab time API in that repo's feature/scarab2 branch.