Csv import: GncDateFormat ->date_locale

[christopherlam]

offshoot #1710 -- here's attempt.

all GncDateFormat changed to use locales. The locale combobox is currently 799 items long!

but it doesn't seem to parse all dates. see example with debugging code. looks like ICU type issue which cannot understand "Sep" yet can understand "Apr".

[jralls]

It didn't like Jun either. Does changing the locale change anything?

[christopherlam]

It didn't like Jun either. Does changing the locale change anything?

not really! "Jun" "Jul" are also off. "September" is accepted.

[christopherlam]

oops

with en_US.utf8 "Sep":fail "Jun":fail "Jul":fail -- I guess it expects m/d/y
with en_AU.utf8 "Sep":fail "Jun":fail "Jul":fail
with en_GB.utf8 "Sep":fail "Jun":pass "Jul":pass
with en_CA.utf8 similar to en_GB

[jralls]

It's partly explained here: en_US: Jun, Jul, Sep; en_AU: June, July, Sept; en_GB: Jun, Jul, Sept; en_CA: Jun, Jul, Sep.

That says it should work for US and CA. A decent parser should be able to deal with dd MMM YYYY regardless of the locale's normal output format.

[jralls]

You forgot to add the tuple to the cache.

[christopherlam]

I didn't: see the magic & in auto& ☺️
I did test via printfs

[christopherlam]

The std::move is slightly beyond my current understanding but it's a requirement for compilation to succeed. Chatgpt did suggest it.

[jralls]

see the magic & in auto&

Very clever. I did miss that indeed.

The std::move is slightly beyond my current understanding

[std::tuple](http://en.cppreference.com/w/cpp/utility/tuple)<unwrap_decay_t<Types>...> make_tuple(Types&&... args)

In template context Types&& means forwarding reference. It needs either a reference or an lvalue. A named variable is an rvalue so it needs to be cast into an lvalue. std::move does that. std::move is apparently confusing. Maybe the committee should have called it lvalue_cast instead.

[flywire]

It's partly explained here: en_AU: June, July, Sept

Seems it is based on poor information. I've never seen that month format in Australia, normally numeric or 3 character alpha.

[christopherlam]

Ok let's kill this stinky hack in favour of #2011

[gjanssens]

Ok.

For posterity, there was a bug in the last attempt, where you try two parsers. If the short parser failed, the medium parser would always fail as well because the parsePos was not reset. Due to this the medium parser always had only a partial string left to parse. By resetting parsePos before attempting the medium parser, I got better results.

Still all these parse attempts are costly. In the ideal case - where only a few parsers are valid - this is ok. However if I test on a string that's valid in many parsers the time to run all the tests add up quickly.

For example with 500 date strings like '06/09/2021', over 600 parsers return a valid date, and the time it takes varies from 2,5 seconds to 3,5 seconds on my system. This can likely be optimized some more by eliminating failing short parsers from the cache. However I don't know if this "intelligent" guessing is really worth it in the end.