All well and good, but useless if the GMT time is wrong (which it is on most of our VM systems, at least as compared to GMT returned from one of the many reliable NTP servers out there). All I want to be able to do is to talk to one of those servers and get an answer as to what time it thinks it is. If it is a few seconds off because of latency I don't care. The system clock I am dealing with are as much as 5 *minutes* off! -- bc
On Tue, Nov 3, 2009 at 10:34 AM, Kris Buelens <[email protected]>wrote: > Yes indeed, but it isn't far away: remember EXEC2? > GMTTIME EXEC A1 V 130 Trunc=130 > ====> > !...+....1....+....2....+....3....+.... > * * * Top of File * * * > &TRACE > CP Q T > CP Q TIMEZONE > &TYPE GMT Date and time: &DATE &TIME > * * * End of File * * * > > TIME IS 16:32:01 CET TUESDAY 2009-11-03 > CONNECT= 05:22:27 VIRTCPU= 000:02.22 TOTCPU= 000:02.38 > Zone Direction Offset Status > UTC ---- 00.00.00 Inactive > GMT ---- 00.00.00 Inactive > CET East 01.00.00 Active > CES East 02.00.00 Inactive > GMT Date and time: 09/11/03 15:32:01 > > 2009/11/3 Paul Gilmartin <[email protected]> > > > On Nov 3, 2009, at 07:54, Bob Cronin wrote: > > > > Our VM clocks are so far off that I wouldn't even care if the > >> answer I got > >> from the ntp server was a few seconds off because of latency... > >> > >> Will VM _ever_ learn to use ETR, STP, whatever? Last I heard it > > couldn't, > > much less being leap second aware. Causes us problems with z/OS guests. > > > > Wonder why GMT isn't among the numerous date() and time() formats > > provided by Rexx? > > > > -- gil > > > > > > -- > Kris Buelens, > IBM Belgium, VM customer support >
