impl From<chrono::DateTime<Utc>> for DtStart, DtEnd, DtStamp

[Cxarli]

It would be very cool if you could do

use ics::{Event, properties::*};
use chrono::prelude::*;

let start = Utc::now();
let end = start + Duration::hours(1);

let mut event = Event::new("Some test event", start);
event.push(DtStart::new(start));
event.push(DtEnd::new(end));

I can understand it if you don't always want to include the chrono dependency for this, but a non-default feature would also be nice.

Since ical's date format does not seem very standard, it doesn't have a conversion function built-in in chrono, meaning you have to do the following yourself:

fn dt_to_ical(dt: DateTime<Utc>) -> String {
        // .format is lazy, so you have to wrap it again inside `format!` to get an actual String
    format!("{}", dt.format("%Y%m%dT%H%M%SZ"))
}
// ...
event.push(DtStart::new(dt_to_ical(start)); // etc

Given that chrono is a pretty popular crate for datetimes, this does not feel very smooth.

[hummingly]

A long time ago I planned to have a typed API but my priorities have shifted, so I usually have barely any time for this crate :/

That said there are a few gotchas but I think it should be feasible to add some support behind a feature flag without a lot of work.

My proposal is to support TryFrom impl for DateTime, NaiveDateTime, Date and NaiveDate for properties with date values.

• Chrono dates support years outside the range 0 to 9999 (4 digits). In theory this can be supported by the format since it uses the ISO 8601 standard but the number of digits must be agreed on by sender and receiver in advance which would break most parsers, I think.
• There are 3 types of dates supported where only two match with a chrono type. NaiveDate(Time) matches with floating times, Date(Time) matches with utc dates but local aware dates use a naive date and a time zone identifier which requires adding a time zone component and a time zone id parameter on the date property. As you can see this requires more information than the Date(Time) gives.
• This bumps the minimum required rustc version but I wanted to update to the 2018 edition anyways.

Tell me what you think!