Does to_rfc3339 produces invalid rfc3339 timestamps with far future times?

[shonfeder]

Given

use chrono::{TimeZone, Utc};
fn main() {
    println!("{:?}", Utc.timestamp(269240665529, 0).to_rfc3339());
}

The result printed, which, iiuc, should either be a valid RFC3339 timestamp (or a panic), is instead:

"+10501-11-24T09:45:29+00:00"

Afaict, that leading + isn't allowed by RFC3339, and I haven't been able to identify any variant that would allow for it.

Am I misunderstanding the expected behavior here, or is something amiss?

[conradludgate]

This issue is still open, so I'll try to give an answer.

All dates and times are assumed to be in the "current era", somewhere between 0000AD and 9999AD.

https://www.rfc-editor.org/rfc/rfc3339#section-1

RFC3339 does not support future yeare beyond 9999, however, ISO8601 does, with the qualifier that 5+ digit dates be prefixed with a +.

To represent years before 0000 or after 9999, the standard also permits the expansion of the year representation but only by prior agreement between the sender and the receiver. An expanded year representation [±YYYYY] must have an agreed-upon number of extra year digits beyond the four-digit minimum, and it must be prefixed with a + or − sign

https://en.wikipedia.org/wiki/ISO_8601#Dates

So you are correct that it's not valid RFC3339. It would be acceptable to error in this case. However returning valid ISO8601 format is also a reasonable thing to to. My thoughts on this issue are inconclusive

[djc]

IMO we should make to_rfc3339() fallible in 0.5.