Skip to content
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

Date strings not always in locale #256

Open
BertLindeman opened this issue Apr 10, 2023 · 9 comments
Open

Date strings not always in locale #256

BertLindeman opened this issue Apr 10, 2023 · 9 comments

Comments

@BertLindeman
Copy link
Contributor

The localized date and times are not always translated,
see in issue 185

I think I found a reason.
In the forcast squares before the day.setText calls I added a setlocale and some prints.

Before and after the setlocale it shows:

BEFORE: in wxfinished_tm3 ('en_US', 'UTF-8') default: ('en_US', 'UTF-8')
AFTER   in wxfinished_tm3: ('nl_NL', 'UTF-8') default: ('en_US', 'UTF-8')

So each time e.g. wxfinished_tm3 is called the locale is again back to the default.

The setlocale is done in the function Tick.
I assume the function tick() runs as a separate thread (or something like it)
Could that be the reason that sometimes I saw the correct locale datea and most of the time not.

I copied the setting of the locale near line 2200 between:

width = rec.width()

signal.signal(signal.SIGINT, myquit)

I added there:

# ================== Set locale here to test if the dates/times ARE in the locales:

if Config.DateLocale != "":
    try:
        locale.setlocale(locale.LC_TIME, Config.DateLocale)
    except Exception as e:
        print("In Tick setlocale failed:", e, "\n\t", Config.DateLocale)
        raise SystemExit(1)

Could this be the cause?

In python3 I did not see a similar problem, but that can be a timing issue aswell.

@SerBrynden
Copy link
Contributor

What happens when you move the following lines from the tick() function to the qtstart() function? Does that fix the issue?

if Config.DateLocale != "":
    try:
        locale.setlocale(locale.LC_TIME, Config.DateLocale)
    except:
        pass

@BertLindeman
Copy link
Contributor Author

Looks like a good idea ;-)

Tried NL DE EN and all with openweathermap and tomorrow.io.
All Ok.

@n0bel
Copy link
Owner

n0bel commented Apr 10, 2023

@SerBrynden's suggestion is the best if it works. tick() is based on QTiimer, which could be a thread or message loop based depending in specific implementation. Setting locale should work 'globally', but you're seeing evidence of two versions of it. It is possible some other time manipulation functions are overriding locale (tz=tzlocal.get_localzone()) for example.

I did intentionally make DateLocale fail silently, in case the operating system does not have the locale set up.

Perhaps another solution is to set locale more often in code that displays data.

Thank you @BertLindeman for helping track this down.

@BertLindeman
Copy link
Contributor Author

Setting locale more often might easily miss some place in the code where it should be. (not formulated very legible, sorry)
But doing it on the one location (and a correct one) would be better.

Another side remark: I did not see this problem running python3.
But not with this excact source due to print incompatibilites.

@SerBrynden
Copy link
Contributor

I saw the same problem in my Python3 fork, until I moved the code to qtstart().

@n0bel
Copy link
Owner

n0bel commented Apr 10, 2023

pull request? or should I just make the change?

@BertLindeman
Copy link
Contributor Author

I want to try.

BertLindeman added a commit to BertLindeman/PiClock that referenced this issue Apr 10, 2023
Moved set locale from tick to qtstart
@BertLindeman
Copy link
Contributor Author

BertLindeman commented Apr 10, 2023

Not doing enough pull requests lately.

Created the pull request. Not sure if I now should close the pull request (now)
[EDIT] chatGPT made me clear that The "Close pull request" button is used to close the pull request without merging it

@SerBrynden
Copy link
Contributor

My latest pull request #258 also fixes this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants