Don't start if locale is not en_US.UTF-8

[rolnas]

Traceback (most recent call last): File "/home/rolnas/.local/bin/not1mm", line 5, in from not1mm.main import run File "/home/rolnas/.local/lib/python3.10/site-packages/not1mm/main.py", line 2274, in window = MainWindow() File "/home/rolnas/.local/lib/python3.10/site-packages/not1mm/main.py", line 356, in init self.check_for_new_cty() File "/home/rolnas/.local/lib/python3.10/site-packages/not1mm/main.py", line 666, in check_for_new_cty update_available = cty.check_update() File "/home/rolnas/.local/lib/python3.10/site-packages/notctyparser/bigcty.py", line 181, in check_update datetime.strptime(date_str, "%d-%B-%Y"), "%Y%m%d" File "/usr/lib/python3.10/_strptime.py", line 568, in _strptime_datetime tt, fraction, gmtoff_fraction = _strptime(data_string, format) File "/usr/lib/python3.10/_strptime.py", line 349, in _strptime raise ValueError("time data %r does not match format %r" % ValueError: time data '26-May-2023' does not match format '%d-%B-%Y'

[rolnas]

Starting with env LC_TIME=en_US.UTF-8 not1mm works OK. On previous version v23.6.2 worked. This problem appeared after today upgrade to 23.6.16.

[mbridak]

I'll have to noodle this a bit. I can't recreate it for some reason.

[mbridak]

What does your LC_TIME normally contain?

[rolnas]

lt_LT.UTF-8 or en_DK.UTF-8

On Sat, 17 Jun 2023, 21:28 Michael Bridak, @.***> wrote:

What does your LC_TIME normally contain?

— Reply to this email directly, view it on GitHub https://github.com/mbridak/not1mm/issues/8#issuecomment-1595825789, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGJ4FDPKHN7CHZY3QSEZWXTXLXZMBANCNFSM6AAAAAAZKAGNEM . You are receiving this because you authored the thread.Message ID: @.***>

[mbridak]

Ok, I trapped the error raised by the notctyparser. I'm opening an issue over on that repo for the issue.

[rolnas]

After lastest update (23.6.17): cty parser returned an error: %s time data '26-May-2023' does not match format '%d-%B-%Y' but at least don't crash, but it doesn't use cty data.

[mbridak]

Yes, but the actual error is being generated by the notctyparser library. I've opened the issue in that repo.

[mbridak]

Okay, I've fixed the problem with notctyparser, and pushed a new version to pypi. I've pinned the new version number of notctyparser in the dependencies list of not1mm. So, if you update not1mm it should download the new notctyparser as well.

Hope this fixes your issue.

[mbridak]

resolved with upstream library.

[rolnas]

Traceback (most recent call last): File "/home/rolnas/.local/bin/not1mm", line 5, in from not1mm.main import run File "/home/rolnas/.local/lib/python3.10/site-packages/not1mm/main.py", line 2316, in window = MainWindow() File "/home/rolnas/.local/lib/python3.10/site-packages/not1mm/main.py", line 380, in init self.check_for_new_cty() File "/home/rolnas/.local/lib/python3.10/site-packages/not1mm/main.py", line 689, in check_for_new_cty cty = notctyparser.BigCty(WORKING_PATH + "/data/cty.json") File "/home/rolnas/.local/lib/python3.10/site-packages/notctyparser/bigcty.py", line 58, in init locale.setlocale(locale.LC_ALL, "en_US") File "/usr/lib/python3.10/locale.py", line 620, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting

Locale en_US doesn't exists, we should use en_US.UTF-8, but better solution would be don't depend on locale settings and save/exchange data in locale independent way.

Locale should be used to show representation of date in local convenient way, not to store data.

[mbridak]

I'm not storing the data that's in question. It's pulling an XML feed http://www.country-files.com/category/big-cty/feed/

which contains to a link to the latest available cty file.

<link>https://www.country-files.com/big-cty-26-may-2023/</link>

I don't have a way to dictate the format of the date given at the end of the link.

[rolnas]

In this case I would write a date parsing code, independing of locale settings. That's because even en_US.UTF-8 locale could be missing on some installations.