This is an interesting problem. In general, combining FIX fields to parse times would require some nontrivial extensions to the message metadata (data dictionary). Another option would be to always use the current UTC date to parse the times. It seems reasonable to interpret a time-only field in that way, although their may be other fields in the message that could specify a different date.

Does UTC have a DST adjustment? I tried googling for it but had trouble finding the answer.

I don't think that UTC has any provisions for DST adjustments at all - it's just meant to be an absolute.
From wikipedia:
The definition for time zones can be written in short form as UTC±n (or GMT±n), where n is the offset in hours. These examples give the local time at various locations at 12:00 UTC when daylight saving time (or summer time, etc.) is not in effect:

So it's explicitly not counting DST. another quote: "a location observing UTC+10 during standard time is at UTC+11 during DST".

i think using using current UTC date to parse time may be a reasonable approach, but then again, i'm sure there'll be situations under which that breaks if we are parsing some historical quotes, for example.

It's quite possible that this is bad design on the part of FIX and we'll just need to have special cases in the application code itself. QFJ may not have enough context to parse everything correctly.

UTC article: http://en.wikipedia.org/wiki/Time_zone#Standard_time_zones
DST article: http://en.wikipedia.org/wiki/Daylight_saving_time#Observance_practices

I agree that the FIX approach of having separate date and time fields is questionable. I'm going the leave the current implementation the way it is for now.

We ended up finding a workflow that works around this fairly cleanly.

We needed to display incoming times from a message in market data refresh with this code:

SimpleDateFormat simpleDateFortmat = new SimpleDateFormat("HH:mm");
simpleDateFormat.setTimeZone(TimeZone.getTimeZone("UTC"));
simpleDateFormat.format(msg.getUTCTimeOnly(MDEntryTime.FIELD))

Since QFJ uses the UTC timezone to parse the time value, this works out just fine.