TimeZone::datetime_from_str incorrectly fails to parse UNIX timestamps as Impossible

[alexchandel]

The following code fails to parse with ParseError(Impossible) when it shouldn't:

Local.datetime_from_str("1510427171.572982", "%s%.f");

There's clearly enough information to parse 1510427171.572982 to a unique datetime in the Local timezone, yet chrono fails. If Local.timestamp(0, 0) produces a valid DateTime<Local>, then there's no reason this example shouldn't as well.

[alexchandel]

The documentation additionally claims "See also Offset::datetime_from_str which gives a local DateTime on specific time zone", but that doesn't seem to exist.

[alexchandel]

In fact, it appears to be impossible to parse a &str reading 1510427171.572982 into any DateTime at all in chrono without reallocating & editing the string.

[alexchandel]

Even NaiveDateTime's parse_from_str, which ac48f51 claims does not require a timezone in the to-be-parsed str, still fails with ParseError(Impossible).

let ts = NaiveDateTime::parse_from_str("1510427171.572982", "%s%.f")?;
Local.from_utc_datetime(&ts)

[alexchandel]

Attempting to manually parse a timestamp, Parsed::to_naive_date and Parsed::to_naive_time both report NotEnough.

However, Parsed::to_naive_datetime_with_offset appears to incorrectly assume that the subsecond value must be zero because a timestamp is present.

Instead of demanding that self.nanosecond be 0, to_naive_datetime_with_offset should only set it to 0 if it's None.

[quodlibetor]

This is indeed a bug in the released chrono (dupe of #175 ), and is fixed in master (5124c0c). If you want to use the updated chrono locally (until @lifthrasiir can release a 0.4.1) I recommend using a [patch] section in your cargo.toml:

[patch.crates-io]
chrono = { git = "https://github.com/chronotope/chrono" }

should do it.