New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detect / configure 'default' date format for importing #325

Closed
hsoft opened this Issue Jun 22, 2013 · 6 comments

Comments

Projects
None yet
1 participant
@hsoft
Owner

hsoft commented Jun 22, 2013

Would it be possible to use the system localisation for date formatting to disambiguate between dd/mm/yyyy and mm/dd/yyyy dates when importing?

A date like "09/04/2012" is clearly ambiguous without context, and I know you do some automatic detection for day, month & year based on the value ranges (e.g. if 16/12/2012 is seen elsewhere in the file, then this would be treated as 9th April rather than 4th September), but the default case still reverts to mm/dd/yyyy if I'm importing data only from the first 12 days of the month. (And I import 3-4 times a month, so about 30% of the time I need to remember to push "Swap Month & Date" in the import wizard, and if I don't, things can get quite messy).

Ideally this would be solved with some look at system localisation settings. I'm running Mac OS X and the "Language & Text" pane in System Preferences has the default date format as dd/mm/yyyy (and other similar formats), and most applications (including moneyGuru) follow this formatting for display of dates. I wonder if moneyGuru could also use that info to configure the default format when parsing dates, if it's ambiguous from the file itself?

If it's not available, then an application preference (or document property) to let me choose it would be useful.

@hsoft hsoft closed this Jun 22, 2013

@hsoft

This comment has been minimized.

Owner

hsoft commented Jun 22, 2013

That's a good idea. I don't know about date format selection upon ambiguity (it might be a lot of effort for what it's worth), but simply prioritizing the local date format would go a long way. It wouldn't work for all cases, but it would be better than the current hardcoded date format priority.

@hsoft

This comment has been minimized.

Owner

hsoft commented Jun 22, 2013

I just thought of something. The current date swapping scheme isn't optimal because it might be hard to be aware that there was an ambiguity during date parsing. It's easy to let a day/month mess up go unnoticed.

What if instead of the current swap choices, there was a combobox with all possible date format choices. Most of the time, this combobox would have only one item (because ambiguities are rather rare), but when there's the possibility of an ambiguity, it will be much easier to spot.

Selecting an item in that combobox wouldn't really trigger a re-parsing (it's not needed) but simply do date swapping like it does now, but to the user, it would look like a new date format is being reapplied to the dates.

@hsoft

This comment has been minimized.

Owner

hsoft commented Jun 22, 2013

That sounds like a much better interface than the date swapping — I'm very likely to know the date format in the file, and also more likely to spot the mis-parsing if the detected format is displayed directly.

(And I guess this might make it easier to default to using the system localisation settings...?)

@hsoft

This comment has been minimized.

Owner

hsoft commented Jun 22, 2013

(from [e60bd1d41fb5]) [#325] Pushed the swap type selector's content and logic down to the core.
https://bitbucket.org/hsoft/moneyguru/changeset/e60bd1d41fb5/

@hsoft

This comment has been minimized.

Owner

hsoft commented Jun 22, 2013

(from [b457ed906833]) [#325] pytest-ified import_window_test.
https://bitbucket.org/hsoft/moneyguru/changeset/b457ed906833/

@hsoft

This comment has been minimized.

Owner

hsoft commented Jun 22, 2013

(from [741ce24a19ad]) [#325 state:fixed] Changed the label of the 3 date swap items in the import window.

Instead of just telling which fields they swap, they display the current and if-fixed date formats, thus improving the clarity of the operation. Moreover, the default date format of the system is tried first (unless the parsed format has a native date format) before trying the whole list of date formats.

That was a lot of work for a seemingly simple feature...
https://bitbucket.org/hsoft/moneyguru/changeset/741ce24a19ad/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment