Created attachment 373204 [details]
Excel example showing dot correctly

Created attachment 373205 [details]
Gnucash example showing commas

I think I'm experiencing a related issue. 

In my case I'm seeing that the date format is ignored, the currency in Preferences is set to USD and in my case it is a dot instead of a comma. 

My setup is:

- Windows 10 1809 Pro with latest patches
- Gnucash 3.5
- Display language in Windows is English
- Country/Region is Swedish
- Format is Swedish with date = yyyy-mm-dd and, with comma and kr as currency
- Current language for non-unicode programs is English

Gnucash 3.4 did not exhibit this problem ( nor previous versions ) but 3.5 for me displays the date in dd/mm/yyyy format, the dot instead of comma but currency is kr in the register but USD in Preferences under "Default locale". 

I've also noted that the numbers stored in the register are now very long, for example if one does a search the Tot Funds In and Tot Funds Out fields would say for example 100.[103 trailing zeros] whereas in 3.4 it would say 100,00.

A minor update, I had to revert back to 3.4 as even scheduled transactions would fail as they tried to insert amount with , instead of .

I compared preferences between 3.5 and 3.4 on the same system and 3.5 claims my default currency, based on my locale, is USD whereas 3.4 correctly reads it as SEK.

It seems that the change in locale handling introduced in 3.5 might be the reason for this behaviour.

I am experiencing the same issue since upgrade from 3.4 to 3.5
I have now updated to 3.5.1 and it is the same.
For me, the impact is:
1. I have needed to "learn" to use the "." as decimal separator instead of the usual "," we use in Europe.
2. All my scheduled transactions have stopped working, since they contain "," as decimal separator.
3. Every time I open GnuCash, I get an error "Invalid Transactions - Error parsing SX [name of my scheduled transaction] key [sx-debit-formula]=formula [50,00] at [50,00]: Undefined carácter." The transaction is created without values, but last execution of the task is not updated, so it runs again next time I open GnuCash.
4. When I run pending schedules manually (Actions / Scheduled Transactions / Since Last Run...", GnuGash crashes.

My workaround for now is to disable aaaaaall Scheduled transactions and create them manuallhy.
I am considering uninstalling 3.5.1 and installing 3.4.

José, what are your Language and Region settings?

Are any of you setting a separate locale using the environment file?

Hi John.
In Windows regional settings I have Spanish. I have also checked the advanced number settings and it has dot for thousands and comma for decimals, as shown in the example: 123.456.789,00
The example for currency shows: 123.456.789,00 €
But in GnuCash Preferences / Accoutns it detects Default Currency Locale: USD.
Date and Time, nevertheless, looks good for Spain: Locale 31/07/2013

When I detected this in 3.5 for the first time I searched and found information about the locale file that I had never touched. I modified these lines:
LANG=es_ES
LANGUAGE={LANG}
But this was causing other issues, breaking my accounting file. I think the issue was with the dates, that GnuCash would not recognize the dates of already entered transactions.
So now I don't have a customized locale file, and the default environment that I think I had not touched has anyway been reset by the installation of 3.5.1 today.

To my eyes, this looks like a partially incorrect read of the regional settings of the operating system, regarding the currency format for both the separators and the symbol.

Hi John,

In my case I had the same problem as José described and I have a similar setup but in my case I have Swedish instead of Spanish. 

I can also confirm that I have never used the environment file. 

I ended up reverting back to 3.4 because I could not use 3.5 due to the failed scheduled transactions, the +130 zeros added to all values under "General Journal" and because of it crashing if I tried to sort in the reconciliation window ( I filed a separate bug for that https://bugs.gnucash.org/show_bug.cgi?id=797198 ).

Trying to check that part of the 130 zeros in the "General Journal" (I don't usually use this). And the number of added dezimal zeros is exactly 102. Examples:
18.030000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
800.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
1,500.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
The number of zeros you reported in the other bug is smaller: 100.0000000000000000000000000000000000000000000000000000000000000000000000
Did you cut the string?

Hi José,


Yeah it was not a straight copy as GnuCash is running on another computer so I just wrote it to illustrate how it looked. 

For me I recall it was ~130 zeros as I copy/pasted the sum into VS Code and looked for number of characters but I can be a few numbers of. In cany case it looks like me and you both have the same issue :)

For me the numbers were visible in the reconcilation window and when trying to edit an entry, in which case it opened the General Journal view. 

I've not had time to dig through the stack or compare the code to see what changes were made between 3.4 and 3.5 with regards to locale but it feels like it is related to that. 

I'll see if I can repro this on a clean W10 with GnuCash and no older data / not upgraded from previous version with the same language / regional settings as I have.

I was able to repro it relatively easy:

1) Clean install of Windows 10 1809 English
2) Downloaded and installed GnuCash 3.5-1
3) Ran through the wizard and selected SEK as default currency, had it auto-create accounts
4) Stored as XML
5) Created new entry, had . instead of , ( gnucash_3.5-1_transaction.png )
6) Currency in preferences is set to USD ( gnucash_3.5-1_currency.png )
7) Trailing zeros present in General Journal ( gnucash_3.5-1_trailingzeros.png )

Regional settings can be seen in gnucash_3.5-1_region.png.

I doublechecked the trailing zeros and they are indeed 102 of them so I must have remembered incorrectly when I filed the bug.

I'll see if I can find a few minutes to spare to do a procmon + log comparison between 3.4 and 3.5 to see what the difference might be when it comes to reading locale settings.

Created attachment 373254 [details]
gnucash_3.5-1_currency.png

Created attachment 373255 [details]
gnucash_3.5-1_region.png

Created attachment 373256 [details]
gnucash_3.5-1_transaction.png

Created attachment 373257 [details]
gnucash_3.5-1_trailingzeros.png

I'll save you the trouble of digging for locale changes between 3.4 and 3.5:

11083d605 Bug 796989 - some date/time does not honor user locale (bis).
140eb0b11 Log a warning in gnc_get_locale() instead of writing to stderr.
67f5dfb03 Bug 796946 - Mortgage and Loan Repayment Setup tool crashes when...
bfadfd7d6 Fix erratic localization of dates on Windows.
8f88b7f2b Restore the global locale after Guile munges it.
7d7da8e2c Bug 797067 - Date displayed incorrectly in register take two.
e31f4c3f9 Fix unlocalized date in status bar.
b4fedff90 Provide a single static instance of C++ locale.
2b6927865 Re-coded for cached locale.
3a105f072 Catch boost::locale character-conversion exceptions.

Most of those have to do with setting and using the C++ localization, which is used for both numbers and dates so your intuition is good.

It was 8f88b7f2b. It turns out that Windows implementation of setlocale works only if the POSIX locale environment variables (i.e. LC_FOO or LANG) are set, otherwise it returns NULL. We were unknowingly relying on Guile to retrieve the Windows environment for us and that would do the wrong thing if the user had set the locale in the environment file, so 8f88b7f2b restored it... unfortunately to the C locale. 

I think I've fixed this, please test with tomorrow's nightly at https://code.gnucash.org/builds/win32/maint.

That was fast John, excellent work in finding and fixing the problem! 

I tested with "gnucash-3.5-2019-04-28-git-3.5-126-g94bb28d9a+.setup.exe" which was the latest build however the bug is not fixed. 

I noticed that the build references the commit prior to your commit that contains the fix for this bug so it looks like the nightly build that would include commit 6c7ccbd9e77fd377c8eae97323fbdadd77d3192f was not generated yet. 

I'll check back later today or tomorrow and get the newer build when it is available to test.

Right, I said *tomorrow's* yesterday. That's https://code.gnucash.org/builds/win32/maint/gnucash-3.5-2019-04-29-git-3.5-130-ga71149713+.setup.exe

Please test again.

Hi John

I am the original poster - sorry I could not take part in the discussions this weekend. Thanks for attending to the issue. 

I installed the 29 April build from the link in Comment 19 above, but I notice no difference to the way the new program uses the locale settings. I first opened an existing .gnucash file, and it still shows commas instead of points. Then I created a new one, using the wizard, and selecting South African Rand as currency, and accepted the default accounts. 

I still cannot type a point, and the comma is still used as separator. Do I need to install something besides GnuCash? I see in the comments above Guile and C locale being mentioned. Maybe I missed something?

Kind regards
Willem

Hi John,

My bad, I forgot the timezone difference so when I woke up I figured it was tomorrow ;) 

I've now tested the latest build and at least on my test machine it works as expected! It correctly reads my regional settings incl currency, comma and as a side effect it also resolved the other bug I filed with trailing zeros and crashing when trying to sort in the recon window.

mkubat, great, thanks. Please close the other bug.

Created attachment 373261 [details]
Windows 10 build 1809 Control Panel>Region, English (South Africa) default currency format.

Willem, when I select English (South Africa) in Control Panel>Region>Additional Settings I get a comma for a decimal separator as shown in the attached screenshot. Did you change it to dot in your Windows settings?

GnuCash doesn't use the Windows localization detail settings, it just gets the locale and uses the standard settings for that locale from the operating system.

Willem, see also https://www.sadev.co.za/content/how-correctly-format-currency-south-africa.

Hi John

 re:
Willem, when I select English (South Africa) in Control Panel>Region>Additional Settings I get a comma for a decimal separator as shown in the attached screenshot. Did you change it to dot in your Windows settings?

No, mine was on dots out of the box when I purchased the PC. It appears changing the language has no effect. When I set my language to English USA, the separator remains a dot. I also went to the location tab and set my home location to USA, and the operating system is still a dot.   

re: "GnuCash doesn't use the Windows localization detail settings, it just gets the locale and uses the standard settings for that locale from the operating system."  -  Any advice then on getting GnuCash to use a point? I still see the comma. As far as I can gather, my operating system "standard" is a point. I have never had a comma, so I do not follow what was fixed then.  

Thanks
Willem

Hi John

re:
Willem, see also https://www.sadev.co.za/content/how-correctly-format-currency-south-africa.

Thanks for the news that the system is changing - I probably lived under a rock the last few years, and I will probably have to adapt in due course. 

But my PC is still set up for points, and the bug report was that GnuCash does not use the Windows set-up that whilst all other software on the laptop follows by the Windows configuration. 

Thanks
Willem

*** Bug 797198 has been marked as a duplicate of this bug. ***

Willem,

We do use dot for the decimal separator and comma for the thousands separator in the US, so of course it stays on dots. Does it change to comma if you select English (Netherlands)?

GnuCash gets the separator value from https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/localeconv?view=vs-2019. Note that that's a POSIX function (GnuCash uses POSIX for portability) and that it works differently from https://docs.microsoft.com/en-us/windows/desktop/api/winnls/nf-winnls-getcurrencyformatex. The latter will read the customization you don't think that you set in Control Panel, the former won't.

All of the other software on your laptop was written for Windows and uses the native Windows localization. GnuCash is written for Unix and uses POSIX localization.

If you want dots, switch to a locale with dots. 

You've been under a rock since 1974? The page refers to: "[2] Measuring Units and National Measuring Standards Act, 1973 (Act No. 76 of 1973), Government Gazette No. 4326, 5 July 1974."

Hi John

Yes, setting to Netherlands changed to a comma. Thanks for the explanation on the two types of functionality. I think I now understand how GnuCash works. 

re: >> All of the other software on your laptop was written for Windows and uses the native Windows localization. GnuCash is written for Unix and uses POSIX localization.
I guess then you should mark my original bug report as "won't fix", as the Windows type customisation will never be applied to GnuCash, and that is what my request implies.  

>> If you want dots, switch to a locale with dots. 
I will follow your advice and do a couple of tests, but I am not sure this solves it. For example if I select English (USA) to get a dot, will this not affect Windows software? Like the Word Processor's spell check could then use USA English spelling instead of South African (British) English spelling etc. So, for Windows software, I want to keep the South African locale.    

>> You've been under a rock since 1974? 
Yes. I started school before then. Using the dot ever since. Possibly will never be able to change. It is in my blood. Much like people still using the Imperial system refuse to switch to Metric.

How about shillings and pence (or was it stuivers and florins in SA)? ;-)

There's English (United Kingdom) which also uses dot for decimal separator and comma for thousands. Or you can change your locale just for GnuCash, see https://wiki.gnucash.org/wiki/Locale_Settings.

I should point out that however you change the locale that it will mess with the default currency. You can override it in Preferences, but you'll need to pay attention when creating new books as the New Book Assistant will pull the default root currency from the locale and you'll have to override that too.

I'm going to leave this as fixed because of the rather serious error that mkubat and José pointed out here.

Hi John

Thanks for your help. I actually logged this issue AFTER reading https://wiki.gnucash.org/wiki/Locale_Settings.   

If I can actually set the locale just for GnuCash, as you mentioned, it would be a solution. but by reading the Wiki, I cannot get it to work. The wiki suggests the following:

1. The Windows instructions in Control panel we have gone over above.   

2. I changed the environment file  to LANG=en_UK. That made zero difference as I can see. (I remembered to uncomment the rows in the file).  I restarted GnuCash, and both existing and a new set of books remain with commas. 

3. Right at the bottom of the wiki is a small note about the securities editor. I fired that up, got confused with the user interface and clicked on the help button. There it says:
>> CURRENCY or ISO4317: These are used for national currencies and are not editable with the Security Editor.

Willem,

Another parameter glitch in calling the Windows setlocale function. I've pushed a commit to fix, please try again with the 1 May nightly.

Hi John,

I had not tested the build from 29th that you linked above.
I have just installed the build from today: https://code.gnucash.org/builds/win32/maint/gnucash-3.5-2019-05-01-git-3.5-136-gbfbb89f6e+.setup.exe

Unfortunatelly, I am still getting the issue. As soon as I opened my mail, all scheduled transactions failed with two errors for each, saying (my translation from spanish): 
"Error of interpretation SX [Name of my transaction] key [sx-debit-formula]=formula [484,80] in [484,80]: Undefined character.
Error of interpretation SX [Name of my transaction] key [sx-credit-formula]=formula [484,80] in [484,80]: Undefined character."

I have checked my preferences in GnuCash and it detects USD as the local currency, but keeps EUR as my selection.
Although in "Accounts" settings, it was set to the default USD.

All the accounts keep showing the numbers with dots as the decimal separator.
The big change I notice is that the application is now in Spanish. With 3.5 it was in English.

I will try to test the build from 29th to check the first changes you commited.

Build from 29th works fine for me in every aspect.
The locale is correctly detected as EUR, ammounts in the transactions are shown with comma as decimal separator and the scheduled transactions worked fine (with the exception of one that I created with version 3.5, failing because it was using a dot instead of a comma.
I don't know what you changed from 29th to 1st of May, but it broke this good behaviour again.

(In reply to John Ralls from comment #32)
> Willem,
> 
> Another parameter glitch in calling the Windows setlocale function. I've
> pushed a commit to fix, please try again with the 1 May nightly.

Hi John

Thanks. After upgrading, I can now set it to display the decimal point by changing the language in the environment file as per the wiki. This solves the issue for me.

Just a question: is it normal behaviour that an upgrade install overwrites the environment file? I had it set from our earlier discussions above, and after upgrading, I had to set the setting again in the file.

Willem,
Yes, it's normal behavior to overwrite the environment file as we use it for some environment variables the program needs. To work around that problem GnuCash also checks for a file named environment.local in the same directory and that one isn't overwritten with a new install.

José,
Dang. I intended to change only the way it handles the environment variables LC_ALL, LC_MESSAGES, and LANG, notably if they're set in the environment file. It shouldn't have affected the case where there's nothing set in the environment but it's obviously trickier than I thought.

José, I missed converting the Windows-style locale to the POSIX-style one in the case where the language wasn't set in the environment file, fixed for tomorrow's nightly.

In the meantime you mentioned in comment 7 that you found some problems when you set the locale in the environment file. I think that should be fixed now too, could you please test it again?

Great, John. The new build looks to be working good regarding the detection of my system locales (EUR) and the use of the comma as the decimal separator.
Pending to check the use of the local configuration file.