-
-
Notifications
You must be signed in to change notification settings - Fork 522
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
Support Little Endian date formats (dd-mm-yyyy) #696
Comments
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. |
I mean, you could also "automagically" detect it from the date format string:
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. |
Fix parsing Journals using a little-endian date format
Hey @wren >>> 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') |
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. |
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. |
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. |
Can you change the date to Day Month Year? Why doesn't JRNL use the locale date setting? |
Not consistently, no. That's why this issue is open.
@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. |
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.
The text was updated successfully, but these errors were encountered: