> We decided to set our 3090 ONCE AND FOREVER to zulu and for daylight
> saving time we only change the offset.
 
At the risk of stating the obvious, I want to point out that the TOD
clock gets reset (typically from the operator's watch or machine room
wall clock) every time the system is booted up, and the operator is
expected (by VM) to enter LOCAL TIME.  The LCL-GMT offset is then
subtracted from the input time to obtain the TOD setting.  Thus, (in
response to Eric's comment) although the TOD clock is running on GMT, a
CP Q TIME always gives the local time, and so does the Time function in
REXX.  There is no reason for mail headers to report GMT (unless it is
marked as such).  NETDATA headers *should* use GMT, however, because
they (a) don't include a time zone code and (b) aren't designed to be
read by humans.
 
>  Sites setting GMT
> and a correct offset change their TOD and leave the offset constant
> for changing to DST and back.
 
This would mean that such sites either use the same time-zone code in
both summer and winter or re-gen the system after changing the zone
code but forgetting to change the offset.  The former is confusing to
outsiders, but the latter would be absurd.  Surely, no one does that.
Re-genning the system twice a year for no good reason is certainly
an annoyance, but there is another way: I devised a CP mod that flips
the offset and zone codes back and forth twice a year automatically
"on the fly" at midnight on the proper Saturday nights.  Programs
running across such breaks might get surprising statistics if they
rely on CP Q TIME answers to measure time intervals, of course, but
they should be reading the TOD clock anyway.
                                  John