The builtin Java classes don't offer this, but ICU's TimeZone class does, and TimeZone.getAvailableIDs("US") provides the correct answer.
The builtin Java classes don't offer this, but ICU's TimeZone class does, and TimeZone.getAvailableIDs("US") provides the correct answer.
As per the documentation the getTimeZone method returns the specified TimeZone, or the GMT zone if the given ID cannot be understood. There's no TimeZone ID called US hence it gives the GMT zone. If you really want to get all the list of TimeZones available in US, I would suggest you to use the following.
final List<String> timeZonesInUS = Stream.of(TimeZone.getAvailableIDs())
.filter(zoneId -> zoneId.startsWith("US")).collect(Collectors.toList());
A Locale is not a TimeZone, and vice versa. Check the Javadoc for the method you're using - the very first line says
Gets a calendar using the default time zone and specified locale.
That's why you're getting the default timezone - since you didn't specify one when obtaining a Calendar.
Think about what Jon said - if you know what timezone you would want to use in the situation where you've worked out a user is from the US, then you can call the Calendar.getInstance method that takes a timezone and a locale. On the other hand, if you can't say definitely what you would do here, then go back to the drawing board and think about your requirements a little more, rather than looking at your implementation.
If you can't answer the previous question, I think the standard recourse of most websites is to allow users to specify their preferred timezone (if they have a persistent account on the server) and default them to the server's timezone if they haven't said otherwise. If they don't have persistent accounts, and they're supplying information to you with times in (e.g. an XML upload), then they will have to either specify what time zone they're using in the request, or (probably better) you mandate the use of UTC for all times.
You can use ICU4J for this... See http://helpdesk.objects.com.au/java/can-i-find-all-available-timezones-for-a-country
tl;dr
ZonedDateTime.now( // Capture the current moment as seen by the wall-clock time used by the people of a certain region (a time zone).
ZoneId.of( "Europe/Paris" ) // Specify time zone by official IANA time zone name. https://en.wikipedia.org/wiki/Tz_database
) // Returns a `ZonedDateTime` object.
.withZoneSameInstant( // Adjust from Paris time to Auckland time, just to show that we can. Same moment, different wall-clock time.
ZoneId.of( "Pacific/Auckland" )
) // Returns a new, second `ZonedDateTime` object without changing (“mutating”) the first. Per immutable objects pattern.
.format( // Generate a String representing the value of our `ZonedDateTime`.
DateTimeFormatter.ofLocalizedDateTime( // Let java.time automatically localize.
FormatStyle.FULL // Specify the length/abbreviation of new String.
) // Returns a `DateTimeFormatter` using the JVM’s current default `Locale`. Override this default in next line.
.withLocale( Locale.ITALIAN ) // Locale is unrelated to time zone. Wall-clock time of Auckland, presented in Italian – perfectly reasonable depending on the needs of your user.
) // Returns a String object holding text that represents the value of our `ZonedDateTime` object.
domenica 8 aprile 2018 08:48:16 Ora standard della Nuova Zelanda
Country does not determine time zone
Current date and time on the basis of country code
No can do.
There is no direct link between country and time zone.
Geographically large countries often straddle multiple time zones, so that the wall-clock time of each region keeps close to solar time (meaning “noon” is when the sun is overhead). Present-day India is unusual in using one time zone across its vast land mass.
Also, there are often enclaves within a country that use a different time zone. This is often related to joining or refusing Daylight Saving Time (DST). For example, in the United States the state of Arizona opts out of the silliness of DST. Yet within Arizona is part of the Navajo Nation which does participate in DST. So neither country nor state/province determines time zone.
Furthermore, there is more to think about than the current offset-from-UTC. A time zone is a history of past, present, and future changes to the offset used by the people of a region. Cutovers in Daylight Saving Time (DST) is one common cause of the offset changing in a zone. Determining earlier/later moments requires a time zone to apply these historical adjustments.
So forget about countries. Specify a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 3-4 letter pseudo-zones such as EST or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "Africa/Tunis" ) ;
Country code as a hint
You could guess, or present a short list for the user to choose from, based on their current geolocation or country code. See the Answer by well on this page for a data file listing the approximately 350 time zones in use since 1970 along with their longitude/latitude and country code.
Excerpt:
…
TK -0922-17114 Pacific/Fakaofo
TL -0833+12535 Asia/Dili
TM +3757+05823 Asia/Ashgabat
TN +3648+01011 Africa/Tunis
TO -2110-17510 Pacific/Tongatapu
TR +4101+02858 Europe/Istanbul
…
Locale & time zone are orthogonal issues
i tried setting locale of specified country as well but i am getting same output ?
Locale has nothing to do with time zone & offset-from-UTC. Locale determines the human language and cultural norms used in localization when generating strings to represent the date-time value. So locale does not affect the meaning.
To localize, specify:
FormatStyleto determine how long or abbreviated should the string be.Localeto determine (a) the human language for translation of name of day, name of month, and such, and (b) the cultural norms deciding issues of abbreviation, capitalization, punctuation, separators, and such.
For example, consider an engineer from Québec attending a conference in India. She will want to view the conference schedule using the Asia/Kolkata time zone to match the time-of-day seen on the clocks on the walls.
LocalDate ld = LocalDate.of( 2018 , Month.JANUARY , 23 ) ;
LocalTime lt =LocalTime.of( 14 , 0 ) ;
ZoneId z = ZoneId.of( "Asia/Kolkata" ) ;
ZonedDateTime zdt = ZonedDateTime.of( ld , lt , z ) ; // Conference session start.
2018-01-23T14:00+05:30[Asia/Kolkata]
But our engineer would prefer to read the text and formatting in her native French, Locale.CANADA_FRENCH.
Locale locale = Locale.CANADA_FRENCH;
DateTimeFormatter f = DateTimeFormatter.ofLocalizedDateTime( FormatStyle.FULL ).withLocale( locale );
String output = zdt.format( f );
mardi 23 janvier 2018 à 14:00:00 India Standard Time
Other time zones
My requirement is to get the current date and time of on the basis of country code like (DE, IT ,ES, IE , PT ,UK)
You can make a new ZonedDateTime using a different time zone but with the same moment (Instant) inside. So you will see a different wall-clock time, yet continue to refer to the same moment, same point on the timeline.
ZoneId zMadrid = ZoneId.of( "Europe/Madrid" ) ;
ZonedDateTime zdtMadrid = zdt.withZoneSameInstant( zMadrid) ; // Same moment, different wall-clock time.
zdtMadrid.toString(): 2018-01-23T09:30+01:00[Europe/Madrid]
Perhaps localize that Spain-zoned moment in Japanese.
DateTimeFormatter fJapan = DateTimeFormatter.ofLocalizedDateTime( FormatStyle.FULL ).withLocale( Locale.JAPAN );
String outputJapan = zdtMadrid.format( fJapan ); // Zone & locale are unrelated, orthogonal issues.
System.out.println(outputJapan);
So we get a Madrid time presented in Japanese language/culture.
2018年1月23日火曜日 9時30分00秒 中央ヨーロッパ標準時
UTC
Generally speaking, you should use UTC values for much of you business logic, logging, storage, and exchange. Simply extract a Instant from our ZonedDateTime. Both the Instant and ZonedDateTime represent the same moment, the same point on the timeline, but viewed using a different wall-clock time.
Instant instant = zdt.toInstant() ; // Capture current moment in UTC.
Going the other direction:
ZonedDateTime zdt = instant.atZone( "Europe/Helsinki" ) ; // Same simultaneous moment, different wall-clock time.
Avoid legacy classes
The troublesome old date-time classes were supplanted years ago by the java.time classes. Instead of Calendar use ZonedDateTime.
ZoneId z = ZoneId.of( "Pacific/Auckland" ) ;
ZonedDateTime zdt = ZonedDateTime.now( z ) ;
For a moment in UTC, Use Instant. The Instant class represents a moment on the timeline in UTC with a resolution of nanoseconds (up to nine (9) digits of a decimal fraction).
Instant instant = Instant.now() ;
About java.time
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes. Hibernate 5 & JPA 2.2 support java.time.
Where to obtain the java.time classes?
- Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
- Java 9 brought some minor features and fixes.
- Java SE 6 and Java SE 7
- Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
- Android
- Later versions of Android (26+) bundle implementations of the java.time classes.
- For earlier Android (<26), the process of API desugaring brings a subset of the java.time functionality not originally built into Android.
- If the desugaring does not offer what you need, the ThreeTenABP project adapts ThreeTen-Backport (mentioned above) to Android. See How to use ThreeTenABP….
I created a table that maps a user's country code to a timezone. If a country has several time zones then the closest time zone to Greenwich Mean Time Zone is taken into account in the table. It's not perfect but it deserves to work.
function country_to_timezone($country_code)
{
$country_code = mb_strtoupper($country_code);
$timezone_list = array('AD' => 'Europe/Andorra',
'AE' => 'Asia/Dubai',
'AF' => 'Asia/Kabul',
'AG' => 'America/Antigua',
'AI' => 'America/Anguilla',
'AL' => 'Europe/Tirane',
'AM' => 'Asia/Yerevan',
'AO' => 'Africa/Luanda',
'AQ' => 'Antarctica/McMurdo',
'AR' => 'America/Argentina/Buenos_Aires',
'AS' => 'Pacific/Pago_Pago',
'AT' => 'Europe/Vienna',
'AU' => 'Australia/Lord_Howe',
'AW' => 'America/Aruba',
'AX' => 'Europe/Mariehamn',
'AZ' => 'Asia/Baku',
'BA' => 'Europe/Sarajevo',
'BB' => 'America/Barbados',
'BD' => 'Asia/Dhaka',
'BE' => 'Europe/Brussels',
'BF' => 'Africa/Ouagadougou',
'BG' => 'Europe/Sofia',
'BH' => 'Asia/Bahrain',
'BI' => 'Africa/Bujumbura',
'BJ' => 'Africa/Porto-Novo',
'BL' => 'America/St_Barthelemy',
'BM' => 'Atlantic/Bermuda',
'BN' => 'Asia/Brunei',
'BO' => 'America/La_Paz',
'BQ' => 'America/Kralendijk',
'BR' => 'America/Noronha',
'BS' => 'America/Nassau',
'BT' => 'Asia/Thimphu',
'BW' => 'Africa/Gaborone',
'BY' => 'Europe/Minsk',
'BZ' => 'America/Belize',
'CA' => 'America/St_Johns',
'CC' => 'Indian/Cocos',
'CD' => 'Africa/Kinshasa',
'CF' => 'Africa/Bangui',
'CG' => 'Africa/Brazzaville',
'CH' => 'Europe/Zurich',
'CI' => 'Africa/Abidjan',
'CK' => 'Pacific/Rarotonga',
'CL' => 'America/Santiago',
'CM' => 'Africa/Douala',
'CN' => 'Asia/Shanghai',
'CO' => 'America/Bogota',
'CR' => 'America/Costa_Rica',
'CU' => 'America/Havana',
'CV' => 'Atlantic/Cape_Verde',
'CW' => 'America/Curacao',
'CX' => 'Indian/Christmas',
'CY' => 'Asia/Nicosia',
'CZ' => 'Europe/Prague',
'DE' => 'Europe/Berlin',
'DJ' => 'Africa/Djibouti',
'DK' => 'Europe/Copenhagen',
'DM' => 'America/Dominica',
'DO' => 'America/Santo_Domingo',
'DZ' => 'Africa/Algiers',
'EC' => 'America/Guayaquil',
'EE' => 'Europe/Tallinn',
'EG' => 'Africa/Cairo',
'EH' => 'Africa/El_Aaiun',
'ER' => 'Africa/Asmara',
'ES' => 'Europe/Madrid',
'ET' => 'Africa/Addis_Ababa',
'FI' => 'Europe/Helsinki',
'FJ' => 'Pacific/Fiji',
'FK' => 'Atlantic/Stanley',
'FM' => 'Pacific/Chuuk',
'FO' => 'Atlantic/Faroe',
'FR' => 'Europe/Paris',
'GA' => 'Africa/Libreville',
'GB' => 'Europe/London',
'GD' => 'America/Grenada',
'GE' => 'Asia/Tbilisi',
'GF' => 'America/Cayenne',
'GG' => 'Europe/Guernsey',
'GH' => 'Africa/Accra',
'GI' => 'Europe/Gibraltar',
'GL' => 'America/Nuuk',
'GM' => 'Africa/Banjul',
'GN' => 'Africa/Conakry',
'GP' => 'America/Guadeloupe',
'GQ' => 'Africa/Malabo',
'GR' => 'Europe/Athens',
'GS' => 'Atlantic/South_Georgia',
'GT' => 'America/Guatemala',
'GU' => 'Pacific/Guam',
'GW' => 'Africa/Bissau',
'GY' => 'America/Guyana',
'HK' => 'Asia/Hong_Kong',
'HN' => 'America/Tegucigalpa',
'HR' => 'Europe/Zagreb',
'HT' => 'America/Port-au-Prince',
'HU' => 'Europe/Budapest',
'ID' => 'Asia/Jakarta',
'IE' => 'Europe/Dublin',
'IL' => 'Asia/Jerusalem',
'IM' => 'Europe/Isle_of_Man',
'IN' => 'Asia/Kolkata',
'IO' => 'Indian/Chagos',
'IQ' => 'Asia/Baghdad',
'IR' => 'Asia/Tehran',
'IS' => 'Atlantic/Reykjavik',
'IT' => 'Europe/Rome',
'JE' => 'Europe/Jersey',
'JM' => 'America/Jamaica',
'JO' => 'Asia/Amman',
'JP' => 'Asia/Tokyo',
'KE' => 'Africa/Nairobi',
'KG' => 'Asia/Bishkek',
'KH' => 'Asia/Phnom_Penh',
'KI' => 'Pacific/Tarawa',
'KM' => 'Indian/Comoro',
'KN' => 'America/St_Kitts',
'KP' => 'Asia/Pyongyang',
'KR' => 'Asia/Seoul',
'KW' => 'Asia/Kuwait',
'KY' => 'America/Cayman',
'KZ' => 'Asia/Almaty',
'LA' => 'Asia/Vientiane',
'LB' => 'Asia/Beirut',
'LC' => 'America/St_Lucia',
'LI' => 'Europe/Vaduz',
'LK' => 'Asia/Colombo',
'LR' => 'Africa/Monrovia',
'LS' => 'Africa/Maseru',
'LT' => 'Europe/Vilnius',
'LU' => 'Europe/Luxembourg',
'LV' => 'Europe/Riga',
'LY' => 'Africa/Tripoli',
'MA' => 'Africa/Casablanca',
'MC' => 'Europe/Monaco',
'MD' => 'Europe/Chisinau',
'ME' => 'Europe/Podgorica',
'MF' => 'America/Marigot',
'MG' => 'Indian/Antananarivo',
'MH' => 'Pacific/Majuro',
'MK' => 'Europe/Skopje',
'ML' => 'Africa/Bamako',
'MM' => 'Asia/Yangon',
'MN' => 'Asia/Ulaanbaatar',
'MO' => 'Asia/Macau',
'MP' => 'Pacific/Saipan',
'MQ' => 'America/Martinique',
'MR' => 'Africa/Nouakchott',
'MS' => 'America/Montserrat',
'MT' => 'Europe/Malta',
'MU' => 'Indian/Mauritius',
'MV' => 'Indian/Maldives',
'MW' => 'Africa/Blantyre',
'MX' => 'America/Mexico_City',
'MY' => 'Asia/Kuala_Lumpur',
'MZ' => 'Africa/Maputo',
'NA' => 'Africa/Windhoek',
'NC' => 'Pacific/Noumea',
'NE' => 'Africa/Niamey',
'NF' => 'Pacific/Norfolk',
'NG' => 'Africa/Lagos',
'NI' => 'America/Managua',
'NL' => 'Europe/Amsterdam',
'NO' => 'Europe/Oslo',
'NP' => 'Asia/Kathmandu',
'NR' => 'Pacific/Nauru',
'NU' => 'Pacific/Niue',
'NZ' => 'Pacific/Auckland',
'OM' => 'Asia/Muscat',
'PA' => 'America/Panama',
'PE' => 'America/Lima',
'PF' => 'Pacific/Tahiti',
'PG' => 'Pacific/Port_Moresby',
'PH' => 'Asia/Manila',
'PK' => 'Asia/Karachi',
'PL' => 'Europe/Warsaw',
'PM' => 'America/Miquelon',
'PN' => 'Pacific/Pitcairn',
'PR' => 'America/Puerto_Rico',
'PS' => 'Asia/Gaza',
'PT' => 'Europe/Lisbon',
'PW' => 'Pacific/Palau',
'PY' => 'America/Asuncion',
'QA' => 'Asia/Qatar',
'RE' => 'Indian/Reunion',
'RO' => 'Europe/Bucharest',
'RS' => 'Europe/Belgrade',
'RU' => 'Europe/Kaliningrad',
'UA' => 'Europe/Simferopol',
'RW' => 'Africa/Kigali',
'SA' => 'Asia/Riyadh',
'SB' => 'Pacific/Guadalcanal',
'SC' => 'Indian/Mahe',
'SD' => 'Africa/Khartoum',
'SE' => 'Europe/Stockholm',
'SG' => 'Asia/Singapore',
'SH' => 'Atlantic/St_Helena',
'SI' => 'Europe/Ljubljana',
'SJ' => 'Arctic/Longyearbyen',
'SK' => 'Europe/Bratislava',
'SL' => 'Africa/Freetown',
'SM' => 'Europe/San_Marino',
'SN' => 'Africa/Dakar',
'SO' => 'Africa/Mogadishu',
'SR' => 'America/Paramaribo',
'SS' => 'Africa/Juba',
'ST' => 'Africa/Sao_Tome',
'SV' => 'America/El_Salvador',
'SX' => 'America/Lower_Princes',
'SY' => 'Asia/Damascus',
'SZ' => 'Africa/Mbabane',
'TC' => 'America/Grand_Turk',
'TD' => 'Africa/Ndjamena',
'TF' => 'Indian/Kerguelen',
'TG' => 'Africa/Lome',
'TH' => 'Asia/Bangkok',
'TJ' => 'Asia/Dushanbe',
'TK' => 'Pacific/Fakaofo',
'TL' => 'Asia/Dili',
'TM' => 'Asia/Ashgabat',
'TN' => 'Africa/Tunis',
'TO' => 'Pacific/Tongatapu',
'TR' => 'Europe/Istanbul',
'TT' => 'America/Port_of_Spain',
'TV' => 'Pacific/Funafuti',
'TW' => 'Asia/Taipei',
'TZ' => 'Africa/Dar_es_Salaam',
'UG' => 'Africa/Kampala',
'UM' => 'Pacific/Midway',
'US' => 'America/New_York',
'UY' => 'America/Montevideo',
'UZ' => 'Asia/Samarkand',
'VA' => 'Europe/Vatican',
'VC' => 'America/St_Vincent',
'VE' => 'America/Caracas',
'VG' => 'America/Tortola',
'VI' => 'America/St_Thomas',
'VN' => 'Asia/Ho_Chi_Minh',
'VU' => 'Pacific/Efate',
'WF' => 'Pacific/Wallis',
'WS' => 'Pacific/Apia',
'YE' => 'Asia/Aden',
'YT' => 'Indian/Mayotte',
'ZA' => 'Africa/Johannesburg',
'ZM' => 'Africa/Lusaka',
'ZW' => 'Africa/Harare'
);
if (!$timezone_list[$country_code]) {
return $country_code;
} else {
return $timezone_list[$country_code];
}
}
I think ICU4J package will help you.
You can shorten your list with hasSameRules()... this should reduce you selection to about 50:
iterate through -> file equal time zones -> choose the most recognizables
The country- list has to have about 200 entries with a whole lot of uninteresting ones such as Gibraltar or St Martin... don't like that idea
