CsvProvider incorrect type for DNB Currency Exchange file about fsharp.data HOT 4 CLOSED

I've just tested with the version on master (not the one from NuGet which is older), and if you specify the "en-us" culture, Dato is recognized as string and Usd is recognized as decimal. The reason for that is that "31.01.2013" is not a valid date under en-us (it would be day 1 of month 31), so it fallbacks to string instead of DateTime. On the other hand, if you specify "nb-no" culture, both Dato and Usd are recognized as dates. The problem is that the decimal-separator is "," and not "." under nb-no, so it's not recognized as a double or decimal, but if you try and DateTime.Parse 5.4833, under both cultures it success to recognize it as May 1st 4833!! :( As a workaround, if you use the "en-gb" culture, it will recognize Dato as a valid datetime and USD as a decimal.

PS: you can pass the url directly to the type provider and create an instance without having to download the file explicitely

let exchange = new FSharp.Data.CsvProvider<"https://www.dnb.no/portalfront/datafiles/miscellaneous/csv/historiske_kurser.csv", ",", "nb-no", 10>()

from fsharp.data.

The root of the problem here is that this csv has dates in a culture, and the rates in another, but that might as well be very common
One possible solution would be for the AsDecimal and AsFloat conversion functions to always accept invariant culture in addition to the culture specified, but that could be dangerous, because "," in the invariant culture (which in fact is en-us) is a thousands separator, and that might make 1,234 to be recognized as 1234. Maybe a better option would be just to not ever allow to convert that to a datetime under any culture, and leave it as a string, probably it would be better.
If we implement #19 this is partially solved, or maybe we could allow culture override per column by adding " (nb-no)" to the header, in a similar way we do it for measures

from fsharp.data.

Thanks for responding to this issue so quickly. And you are of course right, DNB is mixing different formats (Norwegian date and US decimal separator), so understandably the detection is incorrect. Good tip on using the en-us format.

As for passing in the URL, that do not work with the version up on NuGet, but as you said you tested using the version in Master, so might just be new stuff coming in next release.

from fsharp.data.

Thanks for reporting this bug (or oddity) and thanks to @ovatsus for fixing it! It is now in the master and it will be in the next release. I also included this as a test (tpetricek@1c40e94)

from fsharp.data.