Internet time can keep a computer clock useful for ordinary tasks and help prepare an occultation session. It is not a uniform accuracy guarantee. The result depends on the local clock, the time service, the network and the way an application uses the clock. For an occultation, the relevant question is how closely the recorded event is tied to the required time standard, with evidence for that relationship at the moment of observation.
A computer clock needs correction
Wikipedia's crystal-oscillator reference explains that oscillator frequency is used to keep time and that factors including temperature affect the resonant frequency. A computer counts local clock cycles; it does not obtain perfectly correct time merely by running. A small frequency error accumulates into a time offset. Conditions can change during a field session, so a clock checked beforehand can drift while operating without a continuing reference.
NTP, the Network Time Protocol, compares a client's time with that of servers over a network. Requests and replies carry timing information so the client can estimate clock offset and round-trip delay. Repeated exchanges allow the synchronisation process to assess useful measurements and adjust the local clock. The estimate involves a network path, however, rather than direct access to the remote reference clock's instant.
The journey in each direction need not take the same time. Queues, routing and congestion can vary, and an uneven outward and return journey can bias an offset estimate. A quiet local network and a distant public-Internet route therefore present different conditions. The software may reject poor samples, but no attractive clock display proves that all the network effects were negligible during the observation.
Accuracy is conditional
Wikipedia's NTP reference says public-Internet synchronisation can usually stay within tens of milliseconds, while asymmetric routes and congestion can cause errors of 100 ms or more. Those statements describe possible operating conditions, not a measurement of the particular laptop at the telescope. Avoid assigning a quoted typical accuracy to an untested session. Retain the synchronisation status and compare with an independent reference when the result depends on it.
Clock precision, stability and accuracy answer different questions. Precision describes the resolution or consistency of a measurement. Stability concerns how the clock's rate changes. Accuracy concerns its relation to the desired reference. A display with fine subdivisions may simply show a stable offset in great detail. A comparison that checks only a brief interval can miss drift over the longer observation.
Also distinguish the operating-system clock from the application output. A time label added when an image arrives may lag the exposure that produced it. A screen redraw can be delayed after the clock is read. A recorded beep can pass through an audio path with its own buffering. Testing the computer clock alone establishes only part of the timing chain.
Phone apps and web clocks add layers
A phone time app can use a local clock, a network service or a combination of references. A web clock can receive information and then update its display locally. Their apparent agreement with a familiar time display is reassuring for scheduling, but says little about the delay between the indicated time and the visible or audible output. Learn what the software claims to represent before relying on it as an event marker.
Browsers, operating systems and audio playback add scheduling and buffering. A correct time value can therefore produce a late visible change or late sound. Network access can also change or vanish at a field site. Keep a separate record of whether the clock was synchronised and whether a service remained available. If the method depends on an unmeasured output delay, state that limitation instead of treating the output as an exact reference.
The guide to audible time signals follows the route from a time marker to the saved sound. The page on leap seconds addresses a different complication: services can handle a UTC adjustment in different ways. A clock can be internally consistent yet use a convention different from the one assumed by the observation or analysis.
A GPS pulse has a different relationship to the event
A PPS output from a suitable GPS receiver provides an electrical timing edge at the observing equipment. It avoids the particular uncertainty of estimating a remote clock through an internet route. It still needs valid receiver status, a known time standard and a tested connection to the camera or recorder. The GPS-clock guide explains why a pulse marker and the full date-and-time label must be considered together.
Internet time and a GPS-based timer are therefore different arrangements to evaluate, rather than interchangeable displays. The pulse edge can support exposure tagging or an independently tested marker. NTP disciplines a computer clock through exchanges with time servers. Either arrangement still needs scrutiny of the complete path to the recorded event, including any camera or software delay.
IOTA's observing basics identify measuring event times as the central goal of occultation work and advise checking computer or phone time services before using them for observations. Choose a method that has evidence for the needed relationship, not merely a reputation for being accurate. A useful rehearsal records the timing output through the same equipment and settings intended for the event.
The page on judging the quality of time explains independent comparisons. Keep the test result, the equipment state and the actual observation linked. If the timing uncertainty remains larger or less certain than desired, report it honestly. A clearly described limitation is more useful than an unsupported claim that internet synchronisation made the recording exact.