Fixes for IntoValue for chrono::DateTime<Utc> and chrono::DateTime<FixedOffset>

[emwalker]

A recent PR added support for converting to and from chrono::DateTime<Utc> and chrono::DateTime<FixedOffset>. This PR does the following:

• Allow times before the epoch (1970).
• Fix a bug in which Ruby Time objects are created in the system's local timezone rather than the timezone of the chrono datetime.

Due to my lack of knowledge, I have resorted to going through funcall, but I suspect there's a way to do this more efficiently through C API.

[matsadler]

Thanks for this!

I've added time_timespec_new, which takes an offset, so you should be able to use that to avoid funcall.

[matsadler]

You can skip this, the changelog only needs to describe differences from the last release.

[emwalker]

Sounds good.

I noticed some of my checkpoint commits made it into main ("Reviewer comments", etc.). Should I be amending and force pushing to my topic branch to keep a single atomic commit before the PR is merged? Or perhaps you prefer non-atomic commits in main. Let me know if I should do anything specific here.

[matsadler]

I'm not that fussed about how other people structure their commits. I'll merge the PR with the default "Create a merge commit" option on GitHub. If you want a chance to get commits how you like before I merge, just let me know and I can hold off on merging until you give me the ok.

[emwalker]

Should be good to go now, apart from any additional changes you'd like.

[emwalker]

While we're here, I took the liberty of adding support for converting Ruby Time objects for dates prior to 1970 to SystemTime. I believe Ruby's normalization of timespecs will make it unlikely that we'll get a timespec with negative nanoseconds, but I'm not confident of that.

[emwalker]

Now that you've added support for taking a timespec and providing an offset, a question that occurs to me is whether a Time object created from a SystemTime should start out in UTC instead of the system timezone. Perhaps not, since a SystemTime represents a clock on a specific system, even though Time is timezone aware.

[matsadler]

I agree that it seems extremely unlikely that we'll get a timespec with negative nanos, but in this case I don't think there's any harm in having the error handling there just in case.

The way I think about it, Time is a value (seconds from epoch), and a label on how to interpret it (the zone). Like how a string is a value (some bytes) and a label (the encoding).

With my way of thinking about it SystemTime is just a value, without the label (like [u8] vs String). Ruby's Time doesn't have the option to omit the label, so what's the default label?
I'd probably go with UTC being the sensible default (but there might be some bias there having grown up in England basically on the prime meridian). However I think there's a pretty strong case for Ruby having picked local time as the default, so I think we should stick with local.