X-no-Archive:yes
I think that Tom and Stan gave you good answers, so my $.02 may be
redundant. It seems that you have an investment in data with the 'local'
system time zone. One option is to 'convert' to GMT / UT / Zulu time
(different names for the same thing), which is probably going to hurt...
Unless you have reason to believe that you have to work with a very large
number of time zones, there is probably little to be gained. Also, MPE *
likes * to use local time, and * calculates * UT from that (whereas UNIX
does this the other way around). So, local time on the host makes sense.

That said, there is a major difference between how times and even dates
appear in data versus how they appear to the user: 19990520 versus May 20,
1999; 16083884 versus 4:08 PM, that kind of thing. So, your client
'presentation layer' is already 'presenting' the time, so can do what you
need it to do. The big question is how... Any choice can be affected by a
best guess of what your future needs will be.

What hurts (in my view) is that this 'couples' your client to some method on
the host. You can either have the box return local system time and TZ, and
let the client compare the host timezone to its own and calculate as needed
(in which case TZ for the terminal app is useful for the C/S app, if you
choose to go to the trouble, but this method is only useful on the 3000), or
get fancy on the host with some routine that returns UT, and this routine
would have to be duplicated if you ever need to use another host in the mix
(which should be very easy to do).

Actually, I would be interested in hearing how you are currently handling
this. And, are you doing anything to keep the client machines synchronized
somehow with the clock on the 3000, or the 3000 to a public time server?