jrnl doesn't use OS's locale settings when displaying time

[DSiekmeier]

Support Request

Environment

jrnl: v2.8.3
Python: 3.9.1 (tags/v3.9.1:1e5d33e, Dec  7 2020, 17:08:21) [MSC v.1927 64 bit (AMD64)]
OS: Windows 10

What are you trying to do?

Coming from Germany, I would like to see the locale’s full weekday name as described here. So on Fridays, the output should be "Freitag".

What have you tried?

Setting the configuration string to timeformat: '%A %d-%m-%Y %H:%M' did not change the language as I expected.

Other Information

[wren]

Hi, @DSiekmeier. We haven't had many users from other locales, so thank you for filing this issue!

After some testing, it looks like we don't get the system locale properly in jrnl, so this is definitely a bug.

Luckily, it looks like it's a pretty easy fix. We just need to add this somewhere:

import locale
locale.setlocale(locale.LC_ALL, '')

I think we should also add support for a locale value in the config value just in case anyone doesn't want jrnl to use the same locale as their system.

[DSiekmeier]

Sounds good to me.

One might think a little bit about consistency. For example, if jrnl is started the first time, right now a default (english; mm-dd-yyy) format string is used. If the format string in the config will be changed after a few entries to a german one (dd-mm-yyyy), will the entries still be sorted correctly? Or in other words: are the timestamps in the jrnl file independent of the setting in the config?

Also, an approach which is widely used (at least in C / C++ world) is using a environment variable instead of a configuration entry.

[micahellison]

One might think a little bit about consistency. For example, if jrnl is started the first time, right now a default (english; mm-dd-yyy) format string is used. If the format string in the config will be changed after a few entries to a german one (dd-mm-yyyy), will the entries still be sorted correctly? Or in other words: are the timestamps in the jrnl file independent of the setting in the config?

This is a great question, and one we've struggled with for some time. It's already problematic enough that a user could just change the format string without modifying the journal entry, therefore messing with all the timestamps in their journal. What we hope to do in the long run is completely separate storage formats from display formats, so that we use rigid timestamps to get around this.

For now, I think, at the very least, we should document these risks when making this change. I'm open to any other ideas that could help.

Also, an approach which is widely used (at least in C / C++ world) is using a environment variable instead of a configuration entry.

Agreed - the setlocale(locale.LC_ALL, '') snippet that @wren posted above uses this exact approach, which generally consumes the LANG environment variable. But it's also a common convention for a configuration value to take precedence over an environment variable, and I could see some value for this, especially for multilingual users.

[micahellison]

I did some work on this six months ago with PR #1378, but ran into a variety of issues and I am having a hard time mustering the drive to overcome them, especially considering that there's so much lower-hanging fruit to pick from our issues.

If anybody else would like to take this on, please feel free to jump in, either building on what I've done so far or with your own solution.

[SepehrRasouli]

@micahellison Hi, I'm Interested In this issue and i would like to work on it.

This is a great question, and one we've struggled with for some time. It's already problematic enough that a user could just change the format string without modifying the journal entry, therefore messing with all the timestamps in their journal. What we hope to do in the long run is completely separate storage formats from display formats, so that we use rigid timestamps to get around this.

For now, I think, at the very least, we should document these risks when making this change. I'm open to any other ideas that could help.

I think we can convert the current dates to the new local dates, I researched this and found this blog post talking about conversion of these datetimes. What do you think about it ?

[micahellison]

Hi @SepehrRasouli, sorry for the late response. Do feel free to submit a PR if you're interested in working on this. Just please be careful for anything that impacts the storage of dates -- my top concern with this issue is that I don't want someone's dates to be stored incorrectly due to jrnl suddenly recognizing the user's locale.

[SepehrRasouli]

I'm very sorry, I wasn't able to answer. @micahellison Maybe we could fix the problem like this :

• We can add an flag, and if the user passes that flag, we would know that we have to convert all journal dates to local ones. An example can be something like this:

jrnl --convert 

• The user has to specify their local zone in the configuration file to avoid locale settings detection problems
• And that the user has to specify in their config file whether they want to use local times in their jorunals. What do you think about it ? Do you think that this method of handling this problem is efficent ?