Hmm.
I guess the reason this struck me as "broken" is that when dealing with traditional time syntax as presented by software like e-mail/usenet clients, OS log files, or what have you, it is customary -- when a timezone is given simultaneously in abbreviated form (e.g. GMT) and offset form (e.g. +0000) -- for both to refer to the same timezone.
In other words, you never see "-0800 (GMT)" because that would be pointless; everyone already knows that offsets like -8 are always relative to GMT because GMT is world time.
So, rather, when one sees "-0800 (XXX)", the XXX is there for redundancy, to elaborate upon which timezone -0800 happens to
be (as well as to also indicate daylight vs. standard time). E.g., "-0800 (PDT)", telling you that in this case, -0800 means pacific time on daylight savings.
Anyway, that's the convention I've always been accustomed to. So in a sense, assuming $ctime currently = 1281918908 and my OS is configured for the -0800 timezone, when I do (and get) this ...
$asctime($ctime,ddd dd mmm yyyy HH:nn:ss zzz) = Sun 15 Aug 2010 16:35:08 -0800 GMT
$gmt($ctime,ddd dd mmm yyyy HH:nn:ss zzz) = Mon 16 Aug 2010 00:35:08 -0800 GMT
... the results appear broken. $asctime is showing me my current OS time with the correct timezone offset but with the incorrect timezone abbreviation; while $gmt is showing me my OS time as converted to GMT, with the incorrect timezone offset and the correct timezone abbreviation.
