missing support for a plausable format

[petar-dambovaliev]

 Message("07-07-2021 did not match any formats.") } }) // dd-mm-yyyy

[waltzofpearls]

@petar-dambovaliev Thanks for reporting the bug. I will work on a fix.

[SergeyKasmy]

Yeah, I was really excited when I found this library but sadly it's completely useless for me since most of my dates follow dd.mm.yyyy or dd/mm/yyyy formats

[waltzofpearls]

@SergeyKasmy Thanks for reporting this issue. I've been a little busy recently. That said, I will spend some time this weekend and look into this.

The tricky thing for supporting both day first format like dd/mm/yyyy and month first format like mm/dd/yyyy is that it could make input data ambiguous, because the parser needs to determine whether it should use day-month-year or month-day-year, for example, given an input data 01/02/2022, is it February 1st or January 2nd?

One thing I could do is adding another option that can be passed into the parser. This new option can make the parser prefer day-month-year format, and the default preferred format is month-day-year.

[fzgregor]

@waltzofpearls I just ran into the same issue as @SergeyKasmy, which makes your crate unusable for me as well.

I understand that there is an issue with / as separator, but FWIK with . separator there is no country that uses mm.dd.yyyy. Only dd.mm.yyyy is commonly accepted. I briefly checked https://en.wikipedia.org/wiki/Date_format_by_country and found nothing to the contrary.