>>>That's my point...you can't reliably ensure they are the same. The way to have a reliable time is to replace all the DATE(), TIME() and DATETIME() calls with something that gets the date and time from the server.
>>
>>I suppose...
>>Personnally I'd rather threaten a user than have to worry about rewriting a bunch of code whenever I change server software...
>
>People don't always have the luxury of threatening the user. And this doesn't stop anyone from doing this on purpose. In my case, there could be serious legal problems if the date and time are wrong.
>
>And there really isn't a rewrite. Create one function, that checks what network you're on. If on Netware, run NetLib or GPLib and get the result...if on NT, call the function on an Automation server running on the NT server.

There are serious legal repercussions in the event of a bad date and time, yet the users *still* insist on changing these settings?!?!?!?!?!?!?!?! Sounds like you have much larger problems, my friend. For myself, I'd consider it falsifying a company document and terminate the employee on the spot. Wouldn't have too much trouble after that.....