How to reproduce:
In a terminal, run
while true ; do sh -c "clear ; date" | cat ; sleep 1 ; done
then open dateconfig, wait a minute or so, and close it. Regardless of
whether the time is changed, it sets the system time on exit, causing the
time in the other window to jump back.
I can't seem to reproduce this behavior. When you say, "close it", how are you
closing it? Using the Cancel button or the X button in the title bar of the window?
Using the "ok" button. It's not clear to me that clicking "ok" should change
the time if it hasn't been touched.
(Actually, I believe the way this works on some other systems is that the
controls themselves update with the time, so that clicking "ok" sets the time -
but to the current time.)
The function of the OK button is identical to the Apply button except that OK
closes the application after applying the changes. Apply just applies the
changes and does not close the program. The Cancel button is designed to close
the program without applying any changes.
However, there is a small problem. If you start dateconfig, it populates the
entry boxes with the system time when dateconfig was started. If you leave
dateconfig open for a few minutes, and then click OK without changing anything,
it will roll the system clock back to the time that is in the entry boxes (which
is the time that dateconfig was started). I can fix this, but I think it's
pretty minor, considering that you should really click Cancel if you don't want
the changes to take effect. I'm not comfortable changing this in the current
time frame, though. Deferring to a future release.
Fixed in cvs. Now the behavior is that clicking 'Apply' or 'OK' will only
change the time if the user has actually modified the time widgets in some way.