Is there a way to get a timeZone with (only) a country code (valid ISO-3166 code)?

ajeanson picture ajeanson · Sep 7, 2009 · Viewed 31.5k times · Source

I'm trying to get a TimeZone for a user.

For this I have a country code which is a valid ISO Country Code. These codes are the upper-case, two-letter codes as defined by ISO-3166. You can find a full list of these codes at a number of sites, such as: http://www.chemie.fu-berlin.de/diverse/doc/ISO_3166.html

I think the response is "no because it's a manytomany relationship... there can be many timezone for a country like USA ...". That's the problem...

I've tryied something like:

//CountryEnum contains ISO_3166 values (http://www.chemie.fu-berlin.de/diverse/doc/ISO_3166.html) 
  //List all country to test timezone:
  for (int i = 0; i < CountryEnum.values().length; i++) {
   String isoCountryCode = CountryEnum.values()[i].name();// Get the iso country code
   Locale locale = new Locale(isoCountryCode);// Build a country specific locale
   Calendar calendar = Calendar.getInstance(locale);// Build a calendar with the specific locale
   String timeZone = calendar.getTimeZone().getDisplayName();// Build a timeZone with the calendar
   System.out.println("LOCALE : "+locale+" / COUNTRY: "+isoCountryCode+" / TIMEZONE: "+timeZone);
  }

But it always return server TimeZone ...

Any ideas ?

Answer

Andrzej Doyle picture Andrzej Doyle · Sep 7, 2009

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.