who manages the en_ZA locale

Using a DECIMAL POINT to separate the numerical fraction from the whole number, and a COMMA as a grammar separator to distinguish each individual value, it is very easy (and logical) to read out & comprehend this set of numbers - and to import it as a CSV file...

0.8, 14.89, 0.00079, 1.618, 3.14159

0.8 | 14.89 | 0.00079 | 1.618 | 3.14459

Now try reading out or importing this string of numbers in CSV format by using ONLY commas, and your results may vary somewhat...

0,8, 14,89, 0,00079, 1,618, 3,14159

0 | 8 | 14 | 89 | 0 | 00079 | 1 | 618 | 3 | 14159

;)
 
Using a DECIMAL POINT to separate the numerical fraction from the whole number, and a COMMA as a grammar separator to distinguish each individual value, it is very easy (and logical) to read out & comprehend this set of numbers - and to import it as a CSV file...

0.8, 14.89, 0.00079, 1.618, 3.14159

0.8 | 14.89 | 0.00079 | 1.618 | 3.14459

Now try reading out or importing this string of numbers in CSV format by using ONLY commas, and your results may vary somewhat...

0,8, 14,89, 0,00079, 1,618, 3,14159

0 | 8 | 14 | 89 | 0 | 00079 | 1 | 618 | 3 | 14159

;)
Is the question here what is most optimal for importing into excel, or what is the correct format according to South African convention and law?
 
Using a DECIMAL POINT to separate the numerical fraction from the whole number, and a COMMA as a grammar separator to distinguish each individual value, it is very easy (and logical) to read out & comprehend this set of numbers - and to import it as a CSV file...

0.8, 14.89, 0.00079, 1.618, 3.14159

0.8 | 14.89 | 0.00079 | 1.618 | 3.14459

Now try reading out or importing this string of numbers in CSV format by using ONLY commas, and your results may vary somewhat...

0,8, 14,89, 0,00079, 1,618, 3,14159

0 | 8 | 14 | 89 | 0 | 00079 | 1 | 618 | 3 | 14159

;)
But let me humour you for a moment here.

How about importing this string, which happens to be correctly formatted as per South African conventions?

0,8; 14,89; 0,00079; 1,618; 3,14159
 
From Wikipedia...

Comma-separated values is a data format that predates personal computers by more than a decade: the IBM Fortran (level H extended) compiler under OS/360 supported CSV in 1972.[13]

List-directed ("free form") input/output was defined in FORTRAN 77, approved in 1978.

List-directed input used commas or spaces for delimiters, so unquoted character strings could not contain commas or spaces.[14]

The term "comma-separated value" and the "CSV" abbreviation were in use by 1983.[15] The manual for the Osborne Executive computer, which bundled the SuperCalc spreadsheet, documents the CSV quoting convention that allows strings to contain embedded commas, but the manual does not specify a convention for embedding quotation marks within quoted strings.[16]

Comma-separated value lists are easier to type (for example into punched cards) than fixed-column-aligned data, and they were less prone to producing incorrect results if a value was punched one column off from its intended location.

Comma separated files are used for the interchange of database information between machines of two different architectures. The plain-text character of CSV files largely avoids incompatibilities such as byte-order and word size.

The files are largely human-readable, so it is easier to deal with them in the absence of perfect documentation or communication.
[17]

 
But let me humour you for a moment here.

How about importing this string, which happens to be correctly formatted as per South African conventions?

0,8; 14,89; 0,00079; 1,618; 3,14159
Easy - but first, you would have to change the list separator character in the MS Windows regional settings (for both currency & numbers) from the COMMA (the default) to the semi-colon character, and away you go... ;)
 
it has the comma seperator as a dot (.)

it has the decimal seperator as a comma (,)

the date format is not 27 Apr 24, 27/4/24

how can this be changed?
Haven't seen you around of late, so just to confirm - the locale settings as they currently are are indeed correct.
 

South Africa's region settings are wrong. How can I report this?​

The decimal symbol (for numbers and currency) should be a period, not a comma. This causes an astonishing number of problems for South Africans - for example, if you try to create a CSV file in Excel, it uses semi-colon as the separator, which doesn't work with anything. It breaks integration with a lot of software and is causing a great deal of confusion.

I know this is a simple thing for me to change, but Microsoft need to fix this for the entire country.

Link to source here.
 

South Africa's region settings are wrong. How can I report this?​



Link to source here.
The OP there (Gary Jacobson) was clearly as clueless as some of the rest on this forum. I genuinely wonder if he even paid attention at school. Anyway, the last post in that thread summarises your dilemma well:

Well-written software should take the PC's regional settings into account when creating text versions of numbers. That means, as long as a text version of a number stays on the same PC (or same logged-on user) it should all be OK.

For years though, we (South Africans and computer users?) have been using the "international" '.' decimal separator and ',' list separator. To suddenly find (be reminded) that the South African standard is a ',' decimal separator (in numbers and currency) is a bit of a shock. This has caused problems as a result of lazy program writing (e.g. bank statement downloads, and a lot of my own software!)

There is a good investigation into what is correct at


Andrew
 
Some mainframe systems use programming languages & software that predates the switchover from Imperial to Metric systems, and subsequent iterations of the programming code over the ensuing decades have never been revised to make allowances for the move over to the Metric system conventions for number formatting, as that would break the ability to read any older data compiled using the Imperial numbering conventions.

That's why CSV was implemented, to allow the integration of cross-platform data export & import between various operating systems & software, making it more accessible for wider usage.

All I am saying is I know what the 'official rules' are for numbering in South Africa, but some computer systems that use MS Windows to access their data from mainframe systems CANNOT recognize numbers if they are formatted with a comma as the decimal, instead of a full stop; or a semi-colon as the list separator, instead of a comma.

So if you need to deviate from the 'official rules' for English - South Africa (EN-za), when using a Windows 8.x, Windows 10 or Windows 11 laptop or PC, you may then need to change your currency, number, and list separator punctuation symbols in order for users to import & export data between Windows apps and their mainframe systems.

It's up to the specific users or organizations to determine if their numeric formatting requirements need them to deviate from the 'official rules' in order for them to operate correctly.

I prefer the decimal to be a full stop, and NOT a comma, and the list separator for CSV data to be a comma, and NOT a semi-colon - but if you want Windows to display it according to the 'official rules', then by all means, feel free (or obligated, as the case may be) to make the changes to your EN-za regional settings so you can rest comfortably at night, knowing you are 100% fully compliant with the 'official rules'.

I, however, will 'rebel against the establishment' and leave my Windows regional settings for EN-za set as I have customised them.
 
Some mainframe systems use programming languages & software that predates the switchover from Imperial to Metric systems, and subsequent iterations of the programming code over the ensuing decades have never been revised to make allowances for the move over to the Metric system conventions for number formatting, as that would break the ability to read any older data compiled using the Imperial numbering conventions.

That's why CSV was implemented, to allow the integration of cross-platform data export & import between various operating systems & software, making it more accessible for wider usage.

All I am saying is I know what the 'official rules' are for numbering in South Africa, but some computer systems that use MS Windows to access their data from mainframe systems CANNOT recognize numbers if they are formatted with a comma as the decimal, instead of a full stop; or a semi-colon as the list separator, instead of a comma.

So if you need to deviate from the 'official rules' for English - South Africa (EN-za), when using a Windows 8.x, Windows 10 or Windows 11 laptop or PC, you may then need to change your currency, number, and list separator punctuation symbols in order for users to import & export data between Windows apps and their mainframe systems.

It's up to the specific users or organizations to determine if their numeric formatting requirements need them to deviate from the 'official rules' in order for them to operate correctly.

I prefer the decimal to be a full stop, and NOT a comma, and the list separator for CSV data to be a comma, and NOT a semi-colon - but if you want Windows to display it according to the 'official rules', then by all means, feel free (or obligated, as the case may be) to make the changes to your EN-za regional settings so you can rest comfortably at night, knowing you are 100% fully compliant with the 'official rules'.

I, however, will 'rebel against the establishment' and leave my Windows regional settings for EN-za set as I have customised them.
That's the point yes. Customise for your own use case.

The premise of this thread is untrue though.
 
Some mainframe systems use programming languages & software that predates the switchover from Imperial to Metric systems, and subsequent iterations of the programming code over the ensuing decades have never been revised to make allowances for the move over to the Metric system conventions for number formatting, as that would break the ability to read any older data compiled using the Imperial numbering conventions.
When I still worked on mainframe based systems, we exported data as either fixed-format padded with space, or or a tilde ~, or preferably a pipe | as delimiter. Some numpty programmers (or maybe those who migrated for actual terminals to emulators) had the broken pipe (The nearly-untypeable one I posted above) character mapped to their terminal emulator keyboards |. This caused all kinds of drama when interfacing with non-mainframe types though
 
Top
Sign up to the MyBroadband newsletter