Fails to round-trip encode/decode dates

Thank you for these libraries! Unfortunately both msgpackr and cbor-x currently fail on various dates.

For cbor-x, it seems like we start to lose milliseconds due to floating point errors for dates > 2038:

    // Expected: 2039-07-05T16:22:35.792Z
    // Received: 2039-07-05T16:22:35.791Z

    // Expected: 2038-08-06T00:19:02.911Z
    // Received: 2038-08-06T00:19:02.910Z

For msgpackr, it doesn’t seem to have that same floating point error, but it does “wrap around” after 2106:

   // Expected: 2106-08-05T18:48:20.323Z
   // Received: 1970-06-29T12:20:04.323Z

   // Expected: 2110-02-18T14:51:07.995Z
   // Received: 1974-01-12T08:22:51.995Z

FWIW, this comment helped me fix the issue with cbor-x by using string encoding: https://github.com/kriszyp/msgpackr/issues/41#issuecomment-941151807

By encoding as ISO 8601, cbor-x seems to handle any date I throw at it. But the default behavior feels like a bug - the libraries currently don’t properly encode the full range of JS date objects.

IMHO, the default behavior should be to correctly encode any date without any loss, with an option to optimize for message size. But I realize that would be a breaking change - it would be nice if the docs at least mentioned the current limitations of date encoding.

[sbking]

Thank you! It’s working great now

[kriszyp]

Ok, published the fix for date time rounding issue and tag 0 handling in cbor-x@v1.2.1. I also fixed the issue in msgpackr as well. Thank you for the detailed report!