I just upgraded to b129 today, and I've noticed that my system clock is off by (exactly) 5 hours. Fine, so I used the clock app to sync to an NTP server and it pulled the correct time, updating the display and everything. I clicked OK, the time in the upper-right corner of the desktop changed to the correct time, and immediately changed back to 5 hours in the future. This can also be reproduced on the command line:
> pfexec ntpdate 0.pool.ntp.org; date; sleep 1; date 15 Dec 12:52:45 ntpdate[4179]: step time server 207.171.7.151 offset -17999.988088 sec Tuesday, December 15, 2009 12:52:45 PM EST Tuesday, December 15, 2009 5:52:46 PM EST Google suggests that this might be related to the fact that I'm running in a dom0. It seems that Xen exports the system clock in UTC, but *Solaris expects the system clock to be the local time. But I've been in a dom0 with various dev builds for at least three months and never had a clock-related problem. Interestingly, changing my time zone only pushes the clock FORWARD. For example, changing from EST to London time moved my clock ahead five hours (which I would expect; also, it locked my screen, which is a little weird but not unsurprising), but moving it from London back to EST moved the clock ahead five more hours on top of that. However, using ntpdate after that (as above) restores the clock back to where it was originally. Hmm, and on a hunch I just used the clock app to "synchronize now," then manually reduced the number it displayed by 5 hours, and now I have the correct time. But if I run ntpdate after, it breaks the clock again (and locks my screen, which is getting really annoying). So I guess I discovered the workaround, but it would be nice if I knew what was actually going on and why it just now started happening. -- This message posted from opensolaris.org _______________________________________________ opensolaris-help mailing list [email protected]
