In .Net when handling numbers with unspecified locale I use:
return double.Parse(myStr, CultureInfo.InvariantCulture.NumberFormat);
Whats the equivalent in Java? java.util.Locale doesnt seem to include such a thing.
Well, you can use NumberFormat.getNumberInstance().parse();
Related
I don't know java and can't get JavaCall.jl to work with java.text.DecimalFormat. In MATLAB this is very simple -- just check out this link.
Reading the JavaCall.jl documentation, I tried replicating the provided example with DecimalFormat and got this far:
julia>using JavaCall
julia>JavaCall.init(["-Xmx128M"])
julia>jdf = #jimport java.text.DecimalFormat
After that, I got a bunch of errors. (bear in mind: I absolutely have no clue as to how Java works?)
Please help!
It's not clear from the question whether you're looking to know more about JavaCall.jl or just to use some comma separated formatting.
If the latter, then you can use the Formatting.jl package: https://github.com/JuliaIO/Formatting.jl
julia> using Formatting
julia> sprintf1("%'.02f", 123456789)
"123,456,789.00"
And then you don't need any Java.
This package also has a bunch of other formatting options.
When converting Java to C#, what is the proper way to translate Locale to CultureInfo?
I know in C# we have CultureInfo.CurrentCulture for the current thread's culture, and CultureInfo.InvariantCulture for cases where we want to provide consistency for the sake of writing to files. But what do the Java Locale.ROOT and Locale.getDefault() mean, and how do they generally map to the CultureInfo options in C#?
Well, thanks to Andreas, I can surmize from the javadoc:
Locale.ROOT (Java) == CultureInfo.InvariantCulture (C#)
And
Locale.getDefault() (Java) == CultureInfo.CurrentCulture (C#)
I just wish that document was easier to find! I had Googled things like java locale.root equivalent c# and java locale.getdefault equivalent c# with no useful results.
C# has Datetime.FromBinary(long) method which accepts long. I have long data = -8587633342590756227.
Datetime.FromBinary(-8587633342590756227) which gives {7/30/2015 10:10:26 AM}. How to convert it to date-time format in Java?
Thanks
The value .Net (de-)serializes via To-/FromBinary seems very specific to .Net, so I don't think there's an easy way to convert that value into a java.util.Date.
The easiest way I can think of from the perspective of a Java developer would be to convert your .Net DateTime to Unix time (see DateTimeOffset.ToUnixTimeMilliseconds) and then use that value for the java.util.Date constructor that accepts that value.
I am using dynamic string i18n in gwt. For supporting BIDI, i need to know if the locale is RTL or not.
I cannot use
LocaleInfo.getCurrentLocale()
because it will not return the locale value in my case.
Is there a way in GWT to find out if the locale is RTL
If LocaleInfo.getCurrentLocale().isRTL() can't be used and you don't know the current locale (by string representation, at least), you can't know if it is RTL.
If you do have a string representation of the locale in question, you can use GwtLocaleFactory.fromString(...).
Just out of curiosity though, why exactly won't LocaleInfo.getCurrentLocale() return the locale? Is there an error of some sort?
This question already has answers here:
What is the difference between creating a locale for en-US and en_US?
(4 answers)
Closed 9 years ago.
Assume you want to store the locale of user preference in database, which value you will use?
en_US or en-US
They are two standards, but which one you prefer to use as part of your own application?
Updated: Is seems many web sites use dash instead of underscore, e.g.
http://zh.wikipedia.org/zh-tw
http://www.google.com.hk/search?hl=zh-TW
I'm pretty sure "-" is the standard. If you see "_" somewhere it's probably something some people came up with to make it a valid identifier.
Personally I'd go with "-", just to be correct.
http://en.wikipedia.org/wiki/IETF_language_tag
https://datatracker.ietf.org/doc/html/rfc5646
If you're working with Java, you might as well use the Java locale format (en_US).
The BCP 47 documents actually do specify the en-US format, and it's just as common if not more common than Java-style locale names. But in practice you'll see the form with the underbar quite a bit. For example, both Java and most POSIX-type platforms use the underbar for their language/region separator.
So you can't go far wrong with either choice. But given that you're writing in Java and probably targeting a Unix platform, en_US is probably the way to go.
In Java 7, there is a new method Locale.forLanguageTag(String), which assumes the hyphen as a separator. I'd consider that as normative.
Check the documentation of Locale for more information.
en_US. This is a very useful read.
I don't think en-US is a standard at all for Java. (If you see it somewhere could you add a link).
So just use en_US.