On 27 July 2016 at 14:09, Martin Schwidefsky <[email protected]> wrote:
> Are you referring to the RTC clock interface of the kernel? If so then yes, > that never worked for s390. If you look into drivers/rtc/Kconfig you'll > find this: > > No, I meant the HWCLOCK setting in the startup which tried to read the RTC check and then primed the ntp offset with a bogus value. I believe ntpd uses two files with previous offset and drift. It might be interesting if you could manufacture those with the proper offset and prime the ntp offset and do away with the steering. > If I do a "#cp query time" on my z/VM guests I get something like this: > > 00: CP QUERY TIME > 00: TIME IS 14:01:14 CST WEDNESDAY 07/27/16 > 00: CONNECT= 99:59:59 VIRTCPU= 007:13.79 TOTCPU= 007:35.53 > > The interesting part is "CST", which stands for coordinated server time. > And this does not include leap seconds. That implies that your local time > for CP and CMS is not in UTC, no? > > No, I believe "CST" is the time zone name. This might be abusing the abbreviation for "Central Standard Time" as something like "Central Europe Summer Time". If you do a Q TIMEZONE you may find that it's been set to so many hours off GMT (or you see it's linked to STP). The logic in z/VM does not have the leap seconds table built-in, so if you want the right local time then someone must have compensated for the leap seconds (either by hardware clock UTC or LPAR offset to UTC-TA1). Rob ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
