Serde support for millisecond precision timestamps is broken by the lack of truncating i128 to i64.

[JohnDowson]

Causes "i128 is not supported" runtime errors when used with serde_json and/or bson.

time/time/src/serde/timestamp/milliseconds.rs

Line 20 in 0a50218

let timestamp = datetime.unix_timestamp_nanos() / 1_000_000;

serde-rs/json#846

[jhpratt]

While the serde_json issue was closed, I don't see how this isn't an issue on their end. A Unix timestamp in milliseconds, microseconds, or nanoseconds cannot be stored in a 64 bit integer. As far as I can tell this is working as intended; the serializer is where the issue lies.

[JohnDowson]

Can it not? Storing millisecond offset from 01.01.1970 as an i64 should be totally fine for another 200 years, if I'm mathing this correctly.

[jhpratt]

The supported range of years is ±9999 by default and ±999,999 with the large-dates feature enabled.

[JohnDowson]

Though I do agree that not supporting 128 bit integers, and offering to jump straight to bigint as a solution is one of choices of all time.

In the use case where this came up for us, we're writing timestamps to Mongo, which doesn't support 128 bit integers either.
And if you think about it, if serde_json supported 128 bit integers by default, it would unexpectedly break were that 128 bit integer get deserialized by a JavaScript consumer.

[jhpratt]

So…math-wise, 2⁶³ milliseconds is larger than the 1 million supported. As such it was an oversight on my end when this was first implemented. This does not apply to microseconds and nanoseconds, which would be 292,000 years and 292 years respectively.

I'd accept a pull request that duplicates the time::serde::timestamp::milliseconds module as time::serde::timestamp::milliseconds_i64, truncating the value (using num-conv's methods) when serializing and requesting an i64 when deserializing (and similarly calling .extend()).