Develop Reference

Locale.getDefault() vs Locale.English main Difference android kotlin

I am working on android application my application running across the world so I my using local times of all around the world to calculate times of daily activities. The problem which i am facing is that when i want to get time of local country like for example when i use Locale.getDefault() it some times returns values in user's device language for example if a user have a device language Arabic it will return me those values in Arabic format. my logic is design only for English numeric characters when language changes it gives me exception of number format. there is another option which is Locale.English it returns me values in English I want to Ask that if i use Locale.english instead of Locale.getDefault() is there any thing wrong in it or I am doing it in a currect way?

Locale.getDefault().toString() and context.getResources().getConfiguration().locale.toString()
should return the same value.
The only major difference between the two is that the
Locale.getDefault() can be directly overridden by Locale.setDefault(locale). (Which will also affect context.getResources().getConfiguration().locale.toString())

Is there a way to use two locales simultaneously in an app?

I would like to use two locales for resource values in an app.
For example, I want some specific strings to depend on what country the user is in right now (like phone numbers), while the rest of the strings will depend on the phone's language/locale settings.
Is there a clean way of doing this without programatically getting a string resource from a different locale? Or should I be using resources in the first place?

You can set forcefully based on device locale and you will need to handle that pattern when locale check returns true for the particular locale. Also, check for a relevant pattern that needs to be set for example phone number.

Android get system locale different approaches

So, I found out that there are two approaches to get system's locale in Android:
Locale.getDefault()
And
getResources().getConfiguration().locale
Basically question is - can output differ for these two? Or are they always the same and I can use the first one, since it does not require Context object?

Quoted from this page:
Be wary of the default locale
Note that there are many convenience methods that automatically use the default locale, but using them may lead to subtle bugs.
The default locale is appropriate for tasks that involve presenting data to the user. In this case, you want to use the user's date/time formats, number formats, rules for conversion to lowercase, and so on. In this case, it's safe to use the convenience methods.
The default locale is not appropriate for machine-readable output. The best choice there is usually Locale.US – this locale is guaranteed to be available on all devices, and the fact that it has no surprising special cases and is frequently used (especially for computer-computer communication) means that it tends to be the most efficient choice too.
A common mistake is to implicitly use the default locale when producing output meant to be machine-readable. This tends to work on the developer's test devices (especially because so many developers use en_US), but fails when run on a device whose user is in a more complex locale.
For example, if you're formatting integers some locales will use non-ASCII decimal digits. As another example, if you're formatting floating-point numbers some locales will use ',' as the decimal point and '.' for digit grouping. That's correct for human-readable output, but likely to cause problems if presented to another computer (parseDouble(String) can't parse such a number, for example). You should also be wary of the toLowerCase() and toUpperCase() overloads that don't take a Locale: in Turkey, for example, the characters 'i' and 'I' won't be converted to 'I' and 'i'. This is the correct behavior for Turkish text (such as user input), but inappropriate for, say, HTTP headers.

Locale current = getResources().getConfiguration().locale;
You may find that this value is updated more quickly after a settings change if that is necessary for your application.
Which is not in your another method

AFAIK, you can use either, unless your app itself tampers with locale using one way but not the other (Locale.setDefault() but not config.locale or vice versa)
Here's why:
ResourcesManager.applyConfigurationToResourcesLocked() #275:
public final boolean applyConfigurationToResourcesLocked(Configuration config,
CompatibilityInfo compat)
...
// set it for java, this also affects newly created Resources
if (config.locale != null) {
Locale.setDefault(config.locale);
}
Resources.updateSystemConfiguration(config, defaultDisplayMetrics, compat);
ApplicationPackageManager.configurationChanged();
...

Android Time Zone Issue

I am using TimeZone class to get the time zone in SHORT format like "PST", "EST" etc. using TimeZone.getDefault().getDisplayName(false, TimeZone.SHORT, Locale.getDefault())
For some devices this piece of code is returning "PST" etc but some of the devices its returning "GMT+007" value. Anybody has an idea what can be the change I make to make it consistent to "PST" format.

The short name is a part of the time zone database. It seems that some devices are shipping time zone databases that doesn't include this information, or whose libraries ignore it.
To make this consistent I would include a mapping that maps from the long names to the short names. But then you would have to maintain that yourself, and you also need to get the long name (like "US/Hawaii") for each timezone, I don't know if that is possible for you, it depends on the use case.
Please also be aware that the short time zone names are ambiguous, there are many time zones called EST for example.

Localizing the two-letter ISO country codes?

Localizing country names can be done with new Locale("", iso).getDisplayName() but is there a way of localizing ISO codes themselves? In my widget I'm using those to represent various countries. It seems wrong for a language - say, Arabic - to have countries be represented by the two letter ISO code from another alphabet. What are my options here?

By definition, ISO country codes are fixed strings of characters. Their very idea is that they are internationalized, independent of language. They provide the basis for transmitting information about a country in a standardized, language-neutral way; this information can then be displayed in a localized format, but localizing the code would fight against its very purpose.
ISO country codes are meant to be used in machine-readable data, in communication between programs and systems. They are not meant to be displayed to users, though for various reasons, they might be seen by them. Localizing them would still be a wrong move; the correct fix is to change the software that passes them through instead of proper localization.