I found this article.
NET TIME is a foreground command-line task that must be manually run (or scheduled) in order to set the time. In most cases, it requires that each workstation have a batch file or use a login script of some sort to get the time. This means that the time only gets synchronized if the machine successfully logs in to the NT domain AND the login script runs correctly. Unfortunately, these are not foregone conditions on all systems - as you will undoubtably know if you've worked with login scripts before. In addition, NET TIME suffers from other serious limitations:
On Windows NT4/2K/XP/2003/Vista/2008 workstations, the logged-in user must have special rights on the local machine in order to set the time using NET TIME
This is also true of most other time products as well. The local system policies must specifically grant the named user time setting rights or the time sync will fail. Setting and maintaining these rights for Windows NT4/2K/XP/2003/Vista/2008 workstations is very time-intensive for an administrator.
Machines without a time service that do not have a logged-in user cannot synchronize their time.
Some PC clocks (even ones right off the assembly-line) gain or lose several minutes a day. If a machine goes even a weekend without a logged-in user, it can have significant time errors.
NET TIME users at different locations must use different command lines.
Because NET TIME requires a fixed server name in order to use a local server other than the PDC, moving a user to a different office or even network segment can require a reconfiguration of their login or batch files to ensure they get their time from the correct server. Also, see the time zone issues above.
NET TIME doesn't know about network delays and PC clocks.
NET TIME uses Lan Manager protocols that do not take network delays and WANs into account. A workstation synchronizing to a remote server over a slow link can be off by several minutes or more.
NET TIME behaves differently on Windows NT4/2K/XP/2003/Vista/2008 and Win3x/95/98 in how it handles time zones.
On Windows NT4/2K/XP/2003/Vista/2008, if the server that gets contacted is in a different time zone than the client, the server's time is displayed in the time zone of the client (in other words if I'm in Pacific Time on my NT machine, but I happen to authenticate with a server in the Eastern Time zone, the time on my local machine will be set to Pacific time). However, on Win 3.x,95 and 98 machines in the Pacific time zone syncing to an Eastern time zone server would have their time set to Eastern time.
If you are using the /domain option with NET TIME, any other servers running Domain Time Server can service a time request. However, if using a WAN and a local server becomes unavailable (or just slow) for some reason, machines using NET TIME can get their time changed to a different zone if a server in another time zone answers. NET TIME just doesn't know any better.
NET TIME cannot find or use alternate servers if the specified server is unavailable.
NET TIME is a one-server product (with the exception of Domain Time servers running on DCs). If the server specified on the command-line (i.e. in a batch file) is unavailable, the time synchronization will fail.
NET TIME with the /domain option requires the workstation to contact the PDC.
When you run NET TIME without the /domain option, the workstation will iterate through the list of time sources on the network, and contact the first one encountered. By default on an NT or 2000 network, only the PDC is a time source. However, if Domain Time Server is installed on any machine, that machine also becomes a time source. Notice that the NET TIME client won't use the nearest time source -- it will use the first one found in the browser list. It also will not move on to the next source if the first one fails.
Regardless of which time source NET TIME uses, it can take an extended period of time for the NetRemoteTOD call to fail or succeed, and NET TIME does not account for network latencies. In addition, if the NET TIME client happens to be Win95 or Win98, and the time source's time zone settings do not match the client's, the client's time will be wrong.
NET TIME doesn't work well with laptops and remote offices.
The login script problems mentioned above are magnified dramatically if you're using a laptop or workstation remotely, since the workstation may or may not actually authenticate with an NT domain when dialing in (if you're using a PPP dial-in service, or over the Internet using a third-party VPN, for example).
Also, a workstation with a NET TIME command scheduled to run on a schedule (such as the NT AT command) can cause a system using Dial-Up networking to attempt to dial the remote network when it tries to run.
http://www.greyware.com/software/domaintime/product/w32time.asp
