Deprecate DateTime::{from_local, from_utc}

[pitdicker]

I propose to deprecate DateTime::from_local and DateTime::from_utc because they are unergonomic and are easy to misuse.

DateTime::from_local and DateTime::from_utc don't take a type implementing TimeZone as an argument, but an Offset.
So you first somehow need to get the correct offset for that datetime.

This also makes these methods unergonomic: they must be used with type annotations because we can't tell from the offset what the TimeZone type should be.

Example of using DateTime::from_local correctly

let naive = NaiveDate::from_ymd_opt(2000, 1, 12).unwrap().and_hms_opt(2, 0, 0).unwrap();
// Get the offset for this local datetime (`FixedOffset`)
let offset = Local.offset_from_local_datetime(&naive).single().unwrap();
// Construct a `DateTime<Local>`
let datetime = DateTime::<Local>::from_local(naive, offset);

The methods TimeZone::from_local_datetime or NaiveDateTime::and_local_timezone are easier to use.

Can be misused

These methods make it easy to create a DateTime that is invalid. Example:

use chrono::{DateTime, FixedOffset, Local, NaiveDate, TimeZone};
let naive = NaiveDate::from_ymd_opt(2000, 1, 12).unwrap().and_hms_opt(2, 0, 0).unwrap();

// I am pretty sure +18:00 is not your local offset
let offset = FixedOffset::east_opt(18 * 60 * 60).unwrap();
let datetime = DateTime::<Local>::from_local(naive, offset);

let datetime_correct = Local.from_local_datetime(&naive).unwrap();
assert_ne!(datetime, datetime_correct);

Now a DateTime where the offset does not match what the TimeZone would calculate as the offset is not absolutely wrong. A user could change the timezone of Local for example, and any DateTime's created before that would have a different offset.

Are there situations where it makes more sense to take an Offset argument?

Only few.

If a type implementing OffSet belongs to a TimeZone that has a fixed offset, Utc and FixedOffset, it will be just as performant to use the TimeZone::from_local_datetime and TimeZone::from_utc_datetime methods to create a DateTime.

If the TimeZone has an offset that can vary, it is always wrong to reuse an Offset when the naive datetime changes. You should use the the TimeZone::* methods.

The two valid uses I can think of is when an implementer of TimeZone wants to override the provided methods from_local_datetime and from_utc_datetime to create a DateTime (which it should have no reason for), and to recreate a DateTime in something like a deserializer or from FFI.

For those cases I added a new DateTime::from_naive_utc_and_offset method.
It is new instead of keeping from_utc so that users of from_utc get a warning they are probably using a method for something it is not intended for.

[jtmoon79]

Overall, I like this PR, as I agree that those functions are unergonomic. Marking them deprecated with recommendations is a good choice.