Support Little Endian date formats (dd-mm-yyyy)

[pspeter]

Currently all jrnl commands parse dates like "01.10.2019" as mm.dd.yyyy no matter what. This is due to dateutil.parse() defaulting to the medium-endian date format.

#694 fixes part of this issue by using the configured custom date format for reading journals. However, when adding new entries, this is not really an option because then the user always has to supply an hour and minute as well (or risk suddenly getting month and day swapped when his input doesn't completely match the format string).

I propose adding a new configuration "day_first", which is a boolean value that jrnl should just pass to dateutil.parse(dayfirst=day_first). #518 already implemented this change a while ago but sadly was never merged.

Alternatively, we could also try guessing this boolean by parsing the custom format instead of having a separate configuration key for it: Basically checking if the day or the month comes first in the format string. This would require less configuration but it's more "magic" and it may be hard too account for edge cases.

[micahellison]

I'm torn on the best approach. It seems excessive to add a configuration field to identify day-first formats when it's already specified in the format string, but like you brought up, it could be difficult to account for edge cases if we try to automatically detect.

Maybe a separate configuration field is best in the long run. There's some conversation around here around having jrnl manage the config file rather than expecting users to edit it, and if that's the case, jrnl could initialize it on its first run by walking the user through this question in a linear fashion, or maybe even offering default sets of options based on a local provided by the user.

Whatever the case, this is definitely a worthwhile fix considering that most people in the world use day-first dates.

[pspeter]

I mean, you could also "automagically" detect it from the date format string:

1. If the day (%d) comes before the month and the year goes last -> day_first == True.
2. If the month comes before the day and year goes last -> day_first == False.
3. If the year comes before the others -> day_first == False.
4. In other cases, default to day_first == False (should be rare).

I just felt like it might be better to be explicit on this, but I agree that having both in the config feels weird and can also lead to wrong configurations if people don't know what they're doing.

#694 only reverts back to the behavior of <= 1.9.8 when it comes to parsing existing journals by the way, it does not introduce any new day-first logic.

[pspeter]

Hey @wren
While #694 fixed part of the issue, it still doesn't work when composing entries. This issue was meant as a more broad feature request for full support of little endian dates (either using a new config parameter or some other way). dateparser does support a couple ways to change the order, I can show you some examples:

>>> parse("1.2.2019")
datetime.datetime(2019, 1, 2, 0, 0)      # wrong :(

>>> parse("1.2.2019", locales=["de-AT"])
datetime.datetime(2019, 2, 1, 0, 0)      # right!

>>> parse("1.2.2019", locales=["de"])
datetime.datetime(2019, 2, 1, 0, 0)      # right!

>>> parse("1.2.2019", languages=["de"])
datetime.datetime(2019, 2, 1, 0, 0)      # right!

>>> parse("1.2.2019", settings={"DATE_ORDER": "DMY"})
datetime.datetime(2019, 2, 1, 0, 0)      # right!

Also, in unix you can store locale information in environment variables like LC_TIME, maybe jrnl can use those when available?

import locale
>>> locale.setlocale(locale.LC_ALL, "")  # this is necessary to initialize the locale values
'LC_CTYPE=en_US.UTF-8;LC_NUMERIC=en_US.UTF-8;LC_TIME=de_AT.UTF-8;<...>'
>>> locale.getlocale(locale.LC_TIME)
('de_AT', 'UTF-8')

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[xeruf]

I would say use LC_TIME or LC_ALL if set, otherwise default to whatever. No need for a separate config option. I was just confused by this as well, really needs to be supported.

[xeruf]

Oh yikes, here's my issue: I use ISO-dateformat, but would like to enter dd.mm dates. That doesn't work with the logic presented above.

[aindriu80]

Can you change the date to Day Month Year? Why doesn't JRNL use the locale date setting?

[wren]

Can you change the date to Day Month Year?

Not consistently, no. That's why this issue is open.

Why doesn't JRNL use the locale date setting?

@aindriu80 There's actually a draft PR open right now (#1378) to get jrnl to use the locale, but it's still failing some tests. If this is a subject you're familiar with, please feel free to help on the PR.