There's really two different questions here.
First is, how accurately can I measure the time? and the answer is incredibly accurately.
All modern CPUs (like, ~2000 onwards) come with high-resolution timers. On Windows, QueryPerformanceCounter is used to read these; on Linux and other POSIX systems, clock_gettime; on Mac OS X you can use mach_absolute_time or this wrapper that provides a basic POSIX-like clock_gettime wrapper around mach_absolute time.
These timers provide counters measured in nanoseconds, and the practical resolution is usually measured in microseconds. These clocks are also monotonic, meaning they should not go backwards, even if the user adjusts their clock or you're on a multicore CPU system, although there have been buggy BIOSs that caused this for some chips.
The second question is how quickly can I respond to events? and the answer here is much more depressing.
PC operating systems use preemptive multitasking, which means how much time your program gets is completely under the purview of the OS. When you
sleep(10ms), that's a suggestion to the OS. It's rarely perfect, but usually it'll do its best, and you'll wake up sometime within the next 9.9 to 10.1 milliseconds. Sometimes though, it might be 15. Sometimes, if the system is under heavy load, it might be 10000. If an interrupt or signal occurs, it might be 1ms. This is why we have to jump through hoops to get truly stable timesteps in games.
Just knowing the time within 1ms precision? No problem. But relying on game logic that requires more precision than 1ms? That's a tricky business, and probably not appropriate for anything today.