Your plan is rather fraught with peril if the time is now 24 hours ahead and you wish to set it backwards. You really need to understand the consequences of this change. For example, you are going to have "old" files that are newer than files that you just changed. Database timestamps are going to be haywire and you have the very real possability of transaction 2000 occurring before transaction 1000 --- which is rather difficult to explain to a customer. Not to mention, reports may not produce bizarre (if not wrong) output. Makefiles are going to be confused.
Now, reading your question another way, you may be trying to set the time ahead 24 hours. That is much safer --- as long as the change is permanent. In that case, your plan is sound.
Whether or not to use date -u mmddhhmmccyy or simply date mmddhhmmccyy depends entirely upon whether you wish to use your local TZ value to set the time or UTC. In any event, if done correctly, the internal time will be set to the same value.
Note: "The statement the time server is in MST. is a meaningless statement. You should understand that a singlre UNIX box can have multiple TZ's -- all of which are correct for users connected from all over the planet. The system simply counts seconds since 1-Jan-1970; TZ controls how those seconds are displayed. An NTP server has no notion of a timezone. Second mistake: Time Server - singular; you want multiple time servers -- at least 3. That way, your clients can make intelligent, statistical decisions about which time servers are good.
Finanly, don't overlook that stepping the time ahead can also cause critical cron tasks to be missed or executed inappropriately.
If it ain't broke, I can fix that.
