For one thing, this is not how pytz is supposed to be used. You have fallen prey to one of the most common errors when using pytz. See my blog post: https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html

The issue at hand is also more about what `pytz`'s time zones do than anything to do with `datetime.time`. If you use the correct `pytz` interface, you get:

>>> pytz.timezone('Asia/Seoul').localize(time(**t))
pytz/tzinfo.py in localize(self, dt, is_dst)
    321         possible_loc_dt = set()
    322         for delta in [timedelta(days=-1), timedelta(days=1)]:
--> 323             loc_dt = dt + delta
    324             idx = max(0, bisect_right(
    325                 self._utc_transition_times, loc_dt) - 1)

TypeError: unsupported operand type(s) for +: 'datetime.time' and 'datetime.timedelta'

Though this could rightly be called a bug in `pytz`. However, even using `dateutil`, you will find that this doesn't work:

>time(**t, tzinfo=tz.gettz('Asia/Seoul')).isoformat()
'12:31:21.213456'

The reason is that attaching a `tzinfo` to `datetime.time` barely makes sense, and doesn't work if the time zone depends on the day (e.g. anything with DST), because you don't *know* what day it is, so you can't get an offset. As a result, when `isoformat` attempts to query the datetime for `utcoffset()` it gets `None`, and thus has nothing to print.

It works for some of the ones you mentioned because those ones are fixed offsets that never change, and so there *is* a valid value for it, even if no date component is present. See:

>>> time(**t, tzinfo=tz.tzoffset("EST", -18000))
datetime.time(12, 31, 21, 213456, tzinfo=tzoffset('EST', -18000))

>>> time(**t, tzinfo=tz.tzoffset("EST", -18000)).isoformat()
'12:31:21.213456-05:00'

I believe this issue can be closed.