Dates not automatically parsed if they can be integers

[DylanModesitt]

Consider a small deviation from the DateFormat example where the dates could otherwise be interpreted as integers:

data = """
code,date
0,20190101
1,20190102
"""
file = CSV.File(IOBuffer(data); dateformat="yyyymmdd")
file.date

gives

"code,date\n0,20190101\n1,20190102\n"

2-element CSV.File:
 CSV.Row: (code = 0, date = 20190101)
 CSV.Row: (code = 1, date = 20190102)

2-element Vector{Int64}:
 20190101
 20190102

Ideally, I believe this should cause a dateformat match.

[quinnj]

Hmmmm.....I've always been pretty hesitant to do anything like this, since we then open ourselves up to the problem Excel has (which is now the subject of many memes). i.e. the problem becomes someone has a valid int like 20190102 that we say is a Date and now they have to figure out how to go back to an int.

[DylanModesitt]

Ha -- fair enough. Since these styles are not ISO8601, they wouldn't be parsed as dates unless the passed dateformat implies them to be. Of course, then there is some other 8-digit integer column that's not a Date and the meme is fulfilled.

I think it would be nice to include this in the docs for dateformat= though since it could be slightly surprising. Alternatively, we could warn the caller that their dateformat may not be used by default if it would match continuous digits. Good to close this regardless.

[nickrobinson251]

In this case, you can use the types keyword to request the column be a Date e.g.

julia> file = file = CSV.File(IOBuffer(data); dateformat="yyyymmdd", types=Dict(:date => Date))
2-element CSV.File:
 CSV.Row: (code = 0, date = Date("2019-01-01"))
 CSV.Row: (code = 1, date = Date("2019-01-02"))
 
julia> file.date
2-element Vector{Date}:
 2019-01-01
 2019-01-02

Thanks for opening the issue - we'd definitely take a PR adding this as an example in the docs!

---

p.s. We've also recently been discussing possibly in the future supporting an API something like file = CSV.File(x; types=Dict(:date => Date(dateformat="yyyymmdd")) so the type (Date) and the related parsing info (dateformat) would/could be passed together rather than separately... but that's not how things are currently. (cc @drvi, re the TypeConf-idea becoming public API)