Does it matter which NTP time server I choose in Windows?

Does it matter which time server I choose?

Short answer: Yes

Whilst all NTP servers strive to maintain synchronisation with UTC, their distance from you, and the intervening networks, affect NTP factors such as latency and jitter. There is also the question of availability, not all servers are available continuously forever.

So far as I know, UTC and the stratum-0 NTP service is not overseen, regulated or provided by USNO, even within the USA. UTC was defined by the ITU and is based on TAI plus leap seconds (I believe determined by ERS) TAI is maintained by an international set of 70 laboratories (of which USNO is one but also including NRL in Washington and NIST at Boulder) and coordinated by BIPM in France.

I would use the ntp pool for your locale.

How would I know if one was "better" than the others?

By running a real NTP client on a suitable system and looking at the stats

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 connorw600.info europium.canoni 16 u 182d 1024    0    0.000    0.000 4000.00
*dns0.rmplc.co.u ntp1.ja.net      2 u  659 1024  377   27.015   -4.936   1.034
+82.113.154.206  ntp4.ja.net      2 u  700 1024  377   24.853   -4.827   0.788
+dawn.rt.uk.eu.o ntp1.nl.uu.net   2 u  913 1024  377   29.364   -5.614   0.691

Looks like connorw600.info… would be a bad choice.

According to Wikipedia, the Network Time protocol works as follows:

To synchronize its clock with a remote server, the NTP client must compute the round-trip delay time and the offset. The round-trip delay is computed as , where is the time of the request packet transmission, is the time of the request packet reception, is the time of the response packet transmission and is the time of the response packet reception. is the time elapsed on the client side between the emission of the request packet and the reception of the response packet, while is the time the server waited before sending the answer. The offset is given by .

The NTP synchronization is correct when both the incoming and outgoing routes between the client and the server have symmetrical nominal delay. If the routes do not have a common nominal delay, the synchronization has a systematic bias of half the difference between the forward and backward travel times.

From this explanation we can admit that to have an accurate clock synchronization you must have low difference in the delay time that the server respond to your request and the time delay that you answer to the server completing the synchronization. So, if the server that you are running are far away from you (I mean, there are a lot of "points" or routers between you and the NTP server) the probability to have a different "path" for the NTP packets that you receive and you send is increased.

So, from my interpretation of the case, the best server to synchronize your clock is the "closer" one. I mean, if you get a trace of the "points" between you and the server you would choose the one that have fewer jumps. You could use the "tracert" command from Windows to resolve the best public NTP Server for you.

Also, remember that beyond these standard options, there are a lot of public NTP Servers on the Internet.

Short answer: No.

It doesn't matter. They're are all the same. More or less, they're backups for each other. Within the the United States, the Time Service Department of the U.S. Navy Observatory is the official timekeeper. All other mirror its time including corporations, and, specially, any U.S. government entities. Therefore, all the options available from the drop down are same time. Hence there isn't one that is "better" than the others.