In my environment...
java version "1.6.0_02"
Java(TM) SE Runtime Environment (build 1.6.0_02-b06)
Java HotSpot(TM) Client VM (build 1.6.0_02-b06, mixed mode)
"UTC" is a valid time zone ID. Are you seeing otherwise? "UTC" and "GMT" are slightly different.
The directory "<java_home>/lib/zi" contains the names (and definitions) of the time zones distributed with a standard Java JRE/JDK. This directory contains the definition of a time zone (file) called "GMT", but the definition (file) for time zone "UTC" is found in the subdirectory "Etc/UTC". So I guess what I'm saying is that the correct value for the argument of "TimeZone.getTimeZone" should be "Etc/UTC" and not just plain "UTC".
As I said before, calling TimeZone.getTimeZone("UTC") works because "getTimeZone" has logic that defaults to "UTC" in case it doesn't find the requested time zone. This is OK, but when I debug an application built with QuickFIX/J, my "eclipse 3.3" IDE stops inside the JDK code showing the place where a "FileInputStream" throws a "FileNotFoundException" when trying to open a file "UTC" in the directory "<java_home>/lib/zi".
I think I understood your original message. The TimeZone.getTimeZone("UTC") does actually return a UTC timezone object (not GMT) with my version of Java. The TimeZone.getAvailableIDs() method returns both "UTC" and "Etc/UTC" as valid identifiers. Is that the case with your Java environment?
I checked, and my Java environment returns both "UTC" and "Etc/UTC" as valid identifiers. I also double-checked what I said about the fall back code returning "GMT" time zone, and I was wrong. Calling TimeZone.getTimeZone("UTC") worked OK, and no fallback code was executed. My apologies, your code is OK.
No problem. I didn't realize the TimeZone had a fallback of GMT, which seems a little dangerous, so I had to double check the code to be sure I hadn't imagined a UTC timezone (it's been awhile 
). Have a good day.