Could not find date format for "2017-12-02"
Get the error Could not find date format for "2017-12-02" when doingdateparse.ParseAny("2017-12-02")
Golang: 1.9
Thanks for report, but i can't currently reproduce that. Can you try running the https://github.com/araddon/dateparse/tree/master/dateparse Or what OS is this? What time-zone is local?
$ go version
go version go1.9.1 linux/amd64
$ dateparse --timezone="UTC" "2017-12-02"
Your Current time.Local zone is PST
+------------+---------------------------+-------------------------------+-------------------------------+
| method | Zone Source | Parsed | Parsed: t.In(time.UTC) |
+------------+---------------------------+-------------------------------+-------------------------------+
| ParseAny | time.Local = nil | 2017-12-02 00:00:00 +0000 UTC | 2017-12-02 00:00:00 +0000 UTC |
| ParseAny | time.Local = timezone arg | 2017-12-02 00:00:00 +0000 UTC | 2017-12-02 00:00:00 +0000 UTC |
| ParseAny | time.Local = time.UTC | 2017-12-02 00:00:00 +0000 UTC | 2017-12-02 00:00:00 +0000 UTC |
| ParseIn | time.Local = nil | 2017-12-02 00:00:00 +0000 UTC | 2017-12-02 00:00:00 +0000 UTC |
| ParseIn | time.Local = timezone arg | 2017-12-02 00:00:00 +0000 UTC | 2017-12-02 00:00:00 +0000 UTC |
| ParseIn | time.Local = time.UTC | 2017-12-02 00:00:00 +0000 UTC | 2017-12-02 00:00:00 +0000 UTC |
| ParseLocal | time.Local = nil | 2017-12-02 00:00:00 +0000 UTC | 2017-12-02 00:00:00 +0000 UTC |
| ParseLocal | time.Local = timezone arg | 2017-12-02 00:00:00 +0000 UTC | 2017-12-02 00:00:00 +0000 UTC |
| ParseLocal | time.Local = time.UTC | 2017-12-02 00:00:00 +0000 UTC | 2017-12-02 00:00:00 +0000 UTC |
+------------+---------------------------+-------------------------------+-------------------------------+
Same problem here Could not find date format for 18/03/2000
$ go version
go version go1.9.2 darwin/amd64
$ dateparse --timezone="Europe/Amsterdam" "18/03/2000"
Your Current time.Local zone is CET
+------------+---------------------------+-------------------------------------------+-------------------------------------------+
| method | Zone Source | Parsed | Parsed: t.In(time.UTC) |
+------------+---------------------------+-------------------------------------------+-------------------------------------------+
| ParseAny | time.Local = nil | Could not find date format for 18/03/2000 | Could not find date format for 18/03/2000 |
| ParseAny | time.Local = timezone arg | Could not find date format for 18/03/2000 | Could not find date format for 18/03/2000 |
| ParseAny | time.Local = time.UTC | Could not find date format for 18/03/2000 | Could not find date format for 18/03/2000 |
| ParseIn | time.Local = nil | Could not find date format for 18/03/2000 | Could not find date format for 18/03/2000 |
| ParseIn | time.Local = timezone arg | Could not find date format for 18/03/2000 | Could not find date format for 18/03/2000 |
| ParseIn | time.Local = time.UTC | Could not find date format for 18/03/2000 | Could not find date format for 18/03/2000 |
| ParseLocal | time.Local = nil | Could not find date format for 18/03/2000 | Could not find date format for 18/03/2000 |
| ParseLocal | time.Local = timezone arg | Could not find date format for 18/03/2000 | Could not find date format for 18/03/2000 |
| ParseLocal | time.Local = time.UTC | Could not find date format for 18/03/2000 | Could not find date format for 18/03/2000 |
+------------+---------------------------+-------------------------------------------+-------------------------------------------+
ok, thx for the report alex . I see the issue which is the dd/mm/yyyy format which is ambiguous to this type of parsing compared to mm/dd/yyyy . I think the options are:
// for ambiguous
dateparse.ParsePreferEu("18/03/2000")
Or possibly look at time.Local to recognize zones that are dd/mm/yyyy vs mm/dd/yyy
undefined: dateparse.ParsePreferEu
I tried
location, err := time.LoadLocation("Europe/Rome")
if err != nil {
panic(err.Error())
}
date := "18/03/2000"
current, err := dateparse.ParseIn(date, location)
if err != nil {
panic(err.Error())
}
with Could not find date format for 18/03/2000
The funny thing is that native time.* cannot process this date format
Very possibly wrong, but I don't think the time zone affects the disambiguation of the time parser. That format would remain ambiguous regardless of zone, I think. The ParsePreferEu function would do what you want. Additionally, you could write your own wrapper code which parses the time zone name to see if it starts with "Europe", and if so, uses ParsePreferEu, and otherwise parses using another function. Since that assumption won't hold true everywhere, though, I don't know if other users would want it in the main library.
Fairly certain this is actually the same issue as #28