You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Dates not automatically parsed if they can be integers #1040
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.
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.
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)
[comment generated via AI] Documented in #1042 (now on main): numeric inference runs before a custom dateformat, so pass types=Dict(:date => Date) for digit-only dates. Checked on main with Julia 1.12: 20190101 infers Int64 with only dateformat="yyyymmdd" and parses as Date with the types entry.
Activity
quinnj commentedon Oct 21, 2022
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
20190102that we say is a Date and now they have to figure out how to go back to an int.DylanModesitt commentedon Oct 21, 2022
Ha -- fair enough. Since these styles are not ISO8601, they wouldn't be parsed as dates unless the passed
dateformatimplies them to be. Of course, then there is some other 8-digit integer column that's not aDateand 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 theirdateformatmay not be used by default if it would match continuous digits. Good to close this regardless.nickrobinson251 commentedon Oct 21, 2022
In this case, you can use the
typeskeyword to request the column be aDatee.g.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 theTypeConf-idea becoming public API)quinnj commentedon Oct 15, 2026
[comment generated via AI] Documented in #1042 (now on main): numeric inference runs before a custom
dateformat, so passtypes=Dict(:date => Date)for digit-only dates. Checked on main with Julia 1.12:20190101infersInt64with onlydateformat="yyyymmdd"and parses asDatewith thetypesentry.