Interestingly enough, using Int64.MaxValue - 1 as the number of ticks gives:

288/12/31196 02:48:05
288 December 31196

Which is at least consistent (and seems to project back to sanity, i.e. 
31196-12-31).  This is also reproducible with ZonedDateTime too, of course.

I suspect that the underlying problem here is that GregorianCalendarSystem 
defines the maximum [complete] year as 31196, while these dates are in 
somewhere mid-October 31197.  I'm not quite sure why the remainder is spilling 
into the Day field rather than any other (nor why Int64.MaxValue is broken in a 
_different_ way).

Pretty sure we don't need this for 1.0 :-)

I think we need to accept that LocalDateTime (etc) values just don't work 
beyond the advertised year limit of the calendar - and stop them from being 
created. Each calendar can have a pair of LocalInstant values being the 
smallest and largest they'll handle, and every constructor for public types 
will need to check against those.

(Note that the maximum supported year is now slightly lower than it was, to 
make other code more sane.)

Address in 1.3, per issue 215?

At least try to, yes. (CalendarSystem now has MinTicks and MaxTicks - we just 
don't use them much.)

Fixed as part of 2.0. We have a smaller range (-9998 to 9999 ISO, inclusive) 
but we're pretty rigorous about supporting it properly.