> 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