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.