Simple. DOn't use the DATE() function. Don't use the file creation dates from ADIR(). Etc.
Problem is, if you do that, your programs will be severly limited in what they can do. You have to trust a date from somewhere if you want to use date-tracking in your programs. Several ways, but none are absolutely foolproof or problem-free.
You didn't say what your problem was, but an example could be some user whose computer has the wrong date. What do you do if he starts creating records in a table, let's say the invoices table. Well he's off by a couple days, too slow in this case. Before you let him append a record, check the last record in the table and make sure the date/time fields there are not newer than this user's current date/time. If it is, then halt and tell him to adjust his date/time.
Okay, now what do you do if he's 5 minutes or an hour too fast, maybe his computer is out of sync with the Daylight Savings Time. The code in the previous paragraph would let him create a record and proceed but then another user who has the correct time a minute later would be blocked because of this guy who's too fast. Oops!
That's why (1) it is good to synchronize time with the server and (2) if you test the date/time give at least an hour's leeway either way for the guy who's just a little too slow or a little too fast.
dbMark