Libre office - Version: 6.4.7.2
My Libre office Calc is set to recognize numbers that are this format:
“10,12”
My problem is that my data is like this:
“10.12”
Libre thinks that it is a text when I enter.
How I can convert it into the number?
Sorry if this is supposed to be in the comment instead of answer, but I don't have enough reputation to do so...
Assuming you normally use comma as your decimal separator, then the solution you need is here (The article is written for Excel, but it works in Calc too.
):
Convert European Number to US (or vice versa)
The short answer is to use the formula:
=NUMBERVALUE(A2,".",",")
This assumes your data is in A2. Modify accordingly.
IF, however, you ALWAYS want to use period for your decimal separator, then you need to check your settings.
Tools --> Options
Language Settings -> Languages
Decimal separator key: check Same as locale setting (assuming your locale is using . as decimal separator).
Related
Google Sheets currently does something rather obnoxious if you type a number such as 15.5 into a cell - it converts the number into 15/05/2020
I have a sheet file with lots of prices filled in, but every now and then I see these dates pop up... I can't do arithmetics with those dates, and using the "format" command to turn them into money numbers yields crazy stuff, 43.966,00 for example (from the number above)
Is there a workaround for this?
tl;dr - I need the floating point numbers which resemble dates to not become dates when inserted into a cell.
edit:
I didn't include all the information at first, so here we go:
The issue is not only typing in values, I'm actually reading a .csv file and inserting it into sheets via python's pydrive.
The workaround must not be something manual, I'd like my numbers to "show up" correctly in sheets without further manipulating the file.
In Brasil sheets (because of Portuguese i assume) the comma is used as the decimal, not the period. So instead of writing 15.5 you need to write your numbers like 15,5
You can change that by changing the locale of the sheet to somewhere that uses traditional decimal points.
I'm trying to do a simple mail merge in Word 2010 but when I insert an excel field that's supposed to represent a zip code from Connecticut (ie. 06880) I am having 2 problems:
the leading zero gets suppressed such as 06880 becoming 6880 instead. I know that I can at least toggle field code to make it so it works as {MERGEFIELD ZipCode # 00000} and that at least works.
but here's the real problem I can't seem to figure out:
A zip+4 field such as 06470-5530 gets treated like an arithmetic expression. 6470 - 5530 = 940 so by using above formula instead it becomes 00940 which is wrong.
Perhaps is there something in my excel spreadsheet or an option in Word that I need to set to make this properly work? Please advise, thanks.
See macropod's post in this conversation
As long as the ZIP codes are reaching Word (with or without "-" signs in the 5+4 format ZIPs, his field code should sort things out. However, if you are mixing text and numeric formats in your Excel column, there is a danger that the OLE DB provider or ODBC driver - if that is what you are using to get the data - will treat the column as numeric and return all the text values as 0.
Yes, Word sometimes treats text strings as numeric expressions as you have noticed. It will do that when you try to apply a numeric format, or when you try to do a calculation in an { = } field, when you sum table cell contents in an { = } field, or when Word decides to do a numeric comparison in (say) an { IF } field - in the latter case you can get Word to treat the expression as a string by surrounding the comparands by double-quotes.
in Excel, to force the string data type when entering data that looks like a number, a date, a fraction etc. but is not numeric (zip, phone number, etc.) simply type an apostrophe before the data.
=06470 will be interpreted as a the number 6470 but ='06470 will be the string "06470"
The simplest fix I've found is to save the Excel file as CSV. Word takes it all at face value then.
I need to edit format for JFormatedTextField in a Java program. NetBeans are "helping" me with something called Format editor. But, I have no clue how the pattern works.
For #,##0.### , it returns 1,234.567, as pictured above. However, I want to change the thousands delimiter to space and decimal separator to comma.
I would guess # ##0,### is the right format, but no, that returns "Malformed pattern # ##0,###".
How can I change the thousand separator to space and decimal to comma? Is that even possible, using Format editor?
It sounds like you're looking for the reference for the java.text.NumberFormat class.
The DecimalFormatSymbols.getGroupingSeparator method looks like it is probably relevant to what you're doing. You will have to choose an appropriate Locale to get the formatting characters you want.
You may need to do something like:
NumberFormat nf = NumberFormat.getInstance(Locale.FRENCH);
with an appropriate parameter to getInstance() for your country and language.
The question is quiet simple: I've got an arabic text with an US formated Date in it. What is the correct display order of this date? Is it(for instance) 01/10/2009 or 2009/10/1?
The bidi algorithm recognizes the numbers an slashes as neutral and orders them in the same direction like the surrounding text. So the date should be backwards but that's not what any browser does. On the other hand, i can't find any rule in the unicode bidi algorithm which excludes date patterns. So, what is correct here and (especially) why?
without going deep in the technical details
I can tell that 01/10/2009 is the correct one and some times it's 10/01/2009
but it's never 2009/10/1
We are using Firebird as our database. How do we go about storing currency symbols in the database, which character set should we use or what is generally best practice?
For example storing "$" or "¥" appears straight forward, but more complex symbols do not appear correctly in the database table, i.e. "₡" will not store in the database.
What is generally accepted as "best practice" for this kind of thing.
Let me specify that the language we are using is C#. I suspected that UTF8 would be the answer, but how do we go about storing the character in the database, do we use the Unicode, Hex or Decimal equivalent, or do we simply use the character?
Issues with this approach
If you need to output currency text, I would recommend that you do not store the currency symbol associated with the currency data. Even if the symbol is stored in another column and you pull it out as needed. Rather a better approach would be to store the region / locale for the currency data then, format the currency using the regions default formatting. If whatever language/platform you are using doesn't have locale based currency functionality, I still think this is a better approach. In that case, you would do the formatting in a bit of application logic and then display it to the user.
The main reasoning being this is that in different regions and locales not only is the symbol different, but so is the placement of the symbol and the formatting of the currency itself. Also think if you need to distinguish between different types of dollars - maybe at some point you will want to indicate if the dollar amount is in USD, HKD, AUD, etc.
Currency examples
1.234,56€ - Euro (Germany)
€ 1.234,56 - Euro (Netherlands)
€ 1,234.56 - Euro (Ireland)
123,456円 - Yen (Japan)
123,456￥ - Yen (Japan) - yes there are two different currency marks!
Other resources
I found a good article on the MSDN site on currency globalization that helps to better explain the problem.
Here is site on the different formats per locale that for the Euro.
I would point to two main pitfalls:
First, make sure your database is correctly installed as utf-8. Some database force you to chose this at install time, others at schema/user creation time.
Second, make sure the programming language you use supports utf-8. php is especially known to cause problems whith string manipulation and utf-8.
The create database statement for firebird looks as the following:
Make sure you use at least version 2.0 of firebird, the first version to support utf-8.
CREATE DATABASE <database>
USER <username>
PASSWORD <password>
PAGE_SIZE <pagesize>
DEFAULT CHARACTER SET UTF8
Alternatively you can create a single field with
CREATE TABLE money (
SYMBOL VARCHAR(50) CHARACTER SET UTF8 )
Edit: To clarify on what to store: you store exactly the characters as they appear on the screen. Most likely you can just cut/paste them from any program to your database or inside a sql statement. No need to fumble around with conversions to int/hex/oct/ascii whatsoever.
Edit2: Of course you do not store the fully formatted number, but rather only the single currency symbols.
It may also be a Font issue, some Fonts do not have all rare utf-8 characters. For example Arial is missing it. "Lucida Sans Unicode" definately has it. Try setting "Lucida Sans Unicode" in your viewing program.