Utc nanoseconds do not always roundtrip

[crepererum]

Reproducer

Code

#[test]
fn nano_roundrip() {
    let nanos = i64::MIN + 2;
    let dt = Utc.timestamp_nanos(nanos);
    let nanos2 = dt.timestamp_nanos();
    assert_eq!(nanos, nanos2);
}

Expected Result

Test passes.

Actual Result

Test panics when calling dt.timestamp_nanos() (so we don't even get to the actual comparison:

value can not be represented in a timestamp with nanosecond precision.

Technical Background

dt.timestamp() is -9223372037, however nanos / 1_000_000_000 is -9223372036, hence I conclude that this IF branch was taken:

chrono/src/offset/mod.rs

Lines 427 to 430 in b64cedc

	if nanos < 0 {
	secs -= 1;
	nanos += 1_000_000_000;
	}

Hence this checked_mul overflows:

chrono/src/naive/datetime/mod.rs

Line 482 in b64cedc

.checked_mul(1_000_000_000)

My guess is that the conversion routine (first code block) isn't entirely accurate. The conversion is alright, I rather think when converting back we have to be more careful.

[pitdicker]

@crepererum Excellent issue report.

As far as I can tell in this code the first checked_mul pushes the value beyond i64::MIN, and the following addition should bring it back in range. Which of course doesn't work...

    pub fn timestamp_nanos(&self) -> i64 {
        self.timestamp()
            .checked_mul(1_000_000_000)
            .and_then(|ns| ns.checked_add(i64::from(self.timestamp_subsec_nanos())))
            .expect("value can not be represented in a timestamp with nanosecond precision.")
    }

For negative timestamps we should instead add 1 to the timestamp, do the multiply and addition, and subtract 1_000_000_000.

@crepererum Interested in making a PR?

[crepererum]

Fixed by #1294 and released in 0.4.31.