Hi! I think it's reasonable to always parse times with left-aligned milliseconds - otherwise whatever is after the dot is parsed as nanoseconds, leading to (what I assume are) unexpected results.

Before the change:

println!("{:?}", parse_datetime("2022-08-16 19:37:03.123 UTC").unwrap()); 
// 2022-08-16T19:37:03.000000123Z

After:

println!("{:?}", parse_datetime("2022-08-16 19:37:03.123 UTC").unwrap()); 
// 2022-08-16T19:37:03.123Z

QUERY: I'm quite keen to use this library, as I try to migrate from Scala/JVM world to Rust where I can. One of the better (though now really obsolete) libraries in the JVM ecosystem is the Joda datetime handler. What is tripping me up is subtle differences in handling parse for "datetimes" that only contain the date part. For example in scala:

scala> import org.joda.time.DateTime
 
 DateTime.parse("2021-12-02")
import org.joda.time.DateTime

scala> 
scala> res0: org.joda.time.DateTime = 2021-12-02T00:00:00.000Z

whereas in your dateparser, the same kind of parse would yield

[src/main.rs:161] date1 = 2021-12-02T12:06:22.907945488Z

Looking at the code, I can see that you are using current time as "filler" for those fields that are missing. This seems like a perfectly valid approach, but I'm wondering if you would consider extending the API to support passing arbitrary DateTime values to be used as fillier. That would allow me to replicate the behaviour of Joda a little more easily, without having to do a lot of regex parsing and date truncation in my own code.

Reviving https://github.com/waltzofpearls/belt/issues/16

I was wondering if you would consider adding a feature or accepting a PR to allow zeroing out of unknown components?

My use case is I wish to use this parser to parse arbitrary dates where adding the local time makes the dates incorrect. Because I'll be parsing arbitrary data where the input is not under my direct control I will be unable to implement the workaround provided in the previous issue.

...when calling parse with a plain date string. For example:

use dateparser::parse;
use std::error::Error;

fn main() -> Result<(), Box<dyn Error>> {
    let parsed = parse("July 14, 2021")?;
    println!("{:#?}", parsed);
    Ok(())
}

returns a value like 2021-07-14T22:51:35.983216400Z where the time portion happens to be the current local time.

Shouldn't it just return 2021-07-14T00:00:00Z?

Thanks regardless @waltzofpearls !

a date string without time (eg. July 14, 2021) can be parsed into DateTime assigned with local time or midnight at UTC, for example, either 2021-07-14T22:51:35.983216400Z or 2021-07-14T00:00:00Z.

Resolves https://github.com/waltzofpearls/belt/issues/16

• add more internal parsing functions for more formats
• add another function to parse with a specific timezone instead of the default local timezone
• create a new parse struct and move all the internal parsing functions into the struct's impl block as methods

• return type for parse() function changed from Option<DateTime> to Result<DateTime>, error that has to bubble up will be returned, for example, regex parsing error or no matching format to parse input date str
• newtype DateTimeUtc(DateTime) and implemented FromStr for DateTimeUtc, so in addition to calling parse(input), input.parse::() works too

Given chrono's unresolved security advisory - https://rustsec.org/advisories/RUSTSEC-2020-0159,

It'd be nice if dateparser is re-implemented without it.