Timestamp Extension

[ColtonProvias]

A timestamp extension was added to the msgpack spec in August 2017.

https://github.com/msgpack/msgpack/blob/master/spec.md#timestamp-extension-type

I'm already seeing compatibility issues come up with clients and my own software caused by this. The expectation is to conform to the spec, so a plan should be formulated to transition. Maybe allowing for time to be read in both this library's extension and the official extension, but written as per the official extension going forward. And then on a major version release, the current non-official extension is dropped.

[shabbyrobe]

I think I'd prefer to see a major version bump sooner rather than later where the new extension is used by default.

It has been a while since I've tinkered with the guts of msgp, but IIRC there's not really a way to pass flags to msgp's encoding/decoding process that would be consistent across the Marshal/Encode pairs. The way to do that seems to be to use an intermediate type, like what msgp.Number tries to do for the cross-client uint/int problem.

It might be better to plan a clean break and push the old time extension behind a type, like msgp.LegacyTime. It's going to be a bit annoying no matter which way it's sliced, but the goal of "time.Time is provided by the official timestamp method" seems like the only reasonable end.

[philhofer]

I think we should do this version bump along with the changes to integer handling. (I also have a long-standing issue around handling of an empty msgp.Raw that I'd like to sort out.)