When running some tests I came across the following issue. When using:
private String printStandardDate(Date date) {
return DateFormat.getDateTimeInstance(
DateFormat.SHORT, DateFormat.SHORT).format(date);
}
I found this produced different formats of Date depending on the location the tests where run from. So locally in windows / eclipse I got a result: 04/02/12 18:18 but on the Linux box in America I get 2/4/12 6:18 PM
This causes my Tests/Build to fail:
expected:<[04/02/12 18:18]> but was:<[2/4/12 6:18 PM]>
Could anyone explain this behavior?
That's not strange, that's exactly how it's supposed to work.
The API documentation of DateFormat.getDateTimeInstance says:
Gets the date/time formatter with the given date and time formatting styles for the default locale.
The default locale is different on your Windows system than on the Linux box in America.
If you want exact control over the date and time format, use SimpleDateFormat and specify the format yourself. For example:
private String printStandardDate(Date date) {
return new SimpleDateFormat("dd/MM/yy HH:mm").format(date);
}
Even better would be to re-use the SimpleDateFormat object, but beware that it is not thread-safe (if the method might be called from multiple threads at the same time, things will get messed up if those threads use the same SimpleDateFormat object).
private static final DateFormat DATE_FORMAT =
new SimpleDateFormat("dd/MM/yy HH:mm");
private String printStandardDate(Date date) {
return DATE_FORMAT.format(date);
}
The format is based on the default locale in your code. If you want to ensure results you must make sure to use a specific locale. The getDateTimeInstance method is overloaded to offer an alternative method that receives the locale that you want to use as parameter.
public static final DateFormat getDateTimeInstance(int dateStyle,
int timeStyle,
Locale aLocale)
If you use the same locale in both testing environments, the result should be the same.
Related
Like when i take input (he-IL) then output comes like "iw_IL". But i do not want this convert to old iso.
public static void main(String[] args) {
Locale locale = getLocaleIn("he-IL");
System.out.println(locale.toString());
}
private static Locale getLocaleIn(String langCode) {
LocaleCode code = LocaleCode.getByCodeIgnoreCase(langCode);
Locale locale = code.toLocale();
return locale;
}
OutPut:
iw_IL,
Expected Output:
he-IL
Main Problem in Here, In Java Locale.Class:
Finally I Want an Locale Object without Converting to old ISO.
You should avoid non-standard 3rd party classes in problem descriptions, especially when they do not contribute to the problem at all.
We can simply use
Locale locale = new Locale("he", "IL");
System.out.println(locale.toString());
locale = new Locale("iw", "IL");
System.out.println(locale.toString());
and get
iw_IL
iw_IL
under JDK 8, which is in line with the documentation:
This constructor accepts both the old codes ("iw", "ji", and "in") and the new codes ("he", "yi", and "id"), but all other API on Locale will return only the OLD codes.
This has changed with JDK 17:
Obsolete ISO 639 codes ("iw", "ji", and "in") are mapped to their current forms.
and running the same example program with JDK 17 accordingly now prints
he_IL
he_IL
So the cleanest and probably the only solution to your issue would be updating the Java version. Any patch forcing Locale to return the new code in older versions may cause compatibility problems with other components of the runtime relying on the old behavior.
The context:
A customer asked me to help him with a method to format a Joda DateTime with a Locale specified as a parameter.
The problem:
Using "gsw" (Swiss German) as a language does not seem to have an effect on the translation (falls back to English in my case).
"gsw" is part of ISO639-2 (which is ISO639 alpha-3, which the Java locale says it supports, https://docs.oracle.com/javase/8/docs/api/java/util/Locale.html).
I verified to be 100% sure and gsw is part of alpha-3, but it wasn't part of alpha-2 (ISO639-1): https://www.loc.gov/standards/iso639-2/php/English_list.php
I've tried with other languages which are part of alpha-3 but were not present in alpha-2 and I see the same strange behavior.
Have I might not read well enough the Locale helpcenter?
The code:
//all are types belong to joda.time, except Locale, which is java.util
DateTimeZone dtZone = DateTimeZone.forID(IANATimezone);
DateTime dtus = dateTime.withZone(dtZone);
Locale locale = new Locale(Language, Region);
DateTimeFormatter dtf = DateTimeFormat.fullDateTime().withLocale(locale);
So a few days ago I encountered a weird problem however, I didn't change any that kind of code. The problem is the format I'm getting from my method which I used for years. All commas are now spaces (blank fields) and I have no idea what is causing this.
public static String toFancyCost(int num) {
return NumberFormat.getInstance().format((Integer) num);
}
Before even this happened the String I received was looking like for example 2,181,273 and not like 2 181 273.
You must have changed your system locale by accident. The implementation of NumberFormat.getInstance() (on 1.8.0_131):
public final static NumberFormat getInstance() {
return getInstance(Locale.getDefault(Locale.Category.FORMAT), NUMBERSTYLE);
}
It uses formatting specified by the default locale. and the java docs on Locale.getDefault say:
The Java Virtual Machine sets the default locale during startup based
on the host environment. It is used by many locale-sensitive methods
if no locale is explicitly specified. It can be changed using the
setDefault method.
If you were to use NumberFormat.getInstance(Locale) you can specify which locale the NumberFormat should use.
Your systems default local is using a space as thousands separator, number format retured by getInstance() uses settings from system's default local.
As commented above, somehow the system default may have been modified. Let's stick the code to set the locale when formatting by using below to avoid any issues.
int number = 345678987;
NumberFormat numberFormat = NumberFormat.getNumberInstance(Locale.US);// Locale.US or any other locale you required
String numberAsString = numberFormat.format(number);
System.out.println(numberAsString);
response:
345,678,987
when I use the below for example with Locale.CANADA_FRENCH
int number = 345678987;
NumberFormat numberFormat = NumberFormat.getNumberInstance(Locale.CANADA_FRENCH);
String numberAsString = numberFormat.format(number);
System.out.println(numberAsString);
response:
345 678 987
So in your case also locale may have been causing issues, so please explictly set locale.
I have this piece of code in Java
public static void main(String[] args) {
TimeZone tz = TimeZone.getTimeZone("America/Los_Angeles");
System.out.println(tz.getDisplayName(new Locale("ja-JP")));
}
It displays the output "Pacific Standard Time". I would think, it should display this timezone in Japanese? Is this not how this library is supposed to behave?
Use Java's japanese Locale, not your own
System.out.println(tz.getDisplayName(Locale.forLanguageTag("ja-JP")));
or better yet
System.out.println(tz.getDisplayName(Locale.JAPAN));
See here for supported locales in Java 8.
I'm trying to format a date for a given locale new Locale("mk", "MK"). The locale is valid, it returns the country name and language properly. I want to use custom string, in my case "E, kk:mm" or "EEEE, kk:mm". I want the output to be "сабота, 12:00", but what I get is "7, 12:00".
This is how I use it and I tried many ways, but they all seem to behave the same.
SimpleDateFormat sdf = new SimpleDateFormat("EEEE, kk:mm", new Locale("mk", "MK));
sdf.format(new Date());
// output: 7, 12:30
Another method I tried
Calendar calendar = Calendar.getInstance(new Locale("mk", "MK"));
calendar.setTimeInMillis(new Date().getTime());
DateFormat.format("EEEE, kk:mm", calendar);
// output: Saturday, 12:30
I also tried using java.text.DateFormat instead android class, but no change.
The phone locale is set to English, but this is localized app, I want to show dates in a fixed locale format.
I've looked into many SO question regarding this issue and I wasn't able to find answer. I'm not interested in predefined formats, I want to use my own format and I want the date/month names to be formatted for the input locale.
I think the problem is that Macedonia is not a supported locale on the Android JVM. If you run your code as plain Java console app, it's fine. The method Locale.getAvailableLocales() returns 152 members in plain Java, only 88 in an Android emulator. If you have the code snippet:
Locale[] locales = Locale.getAvailableLocales();
String cCode;
for (Locale loc :locales){
cCode = loc.getCountry();
if (cCode.equalsIgnoreCase("MK"))
Toast.makeText(this, cCode, Toast.LENGTH_SHORT).show();
// Or System.out.println() in a Java app
}
Then the toast doesn't show for "MK" although it will println in the Java app
From documentation of SimpleDateFormat:
**Text**: For formatting, if the number of pattern letters is 4 or more,
the full form is used; otherwise a short or abbreviated form is used if
available. For parsing, both forms are accepted, independent of the
number of pattern letters.
So this should fix it:
SimpleDateFormat sdf = new SimpleDateFormat("EEEE, kk:mm", new Locale("mk", "MK"));
NickT was faster :-), so just adding to his answer: if you want to see your locales supported on Android, run:
for (Locale l:Locale.getAvailableLocales()) {
Log.d(l.getDisplayCountry(),l.toString());
}
and you will see that Macedonia is not on the list.