Wait, how was the end-of-line test completed before the device was even assembled!?

Modern cell phones and PCs do a remarkable job of automatically keeping us on time in normal human terms. Daylight savings time does more to upset our sleep schedule than our ability to be on time for a meeting. Every year when the time comes to spring forward or fall backward, a larger share of the clocks around my house automatically oblige.

By default, Windows runs a service called w32tm that will synchronize to time.windows.com using the Network Time Protocol (NTP). W32tm is sophisticated and will discipline (speed-up or slow-down) the PC internal clock based on measured drift from the time server. For normal people, a PC with synchronization every couple days is sufficient. W32tm is highly configurable with the ability to select other time servers or set shorter update intervals. W32tm and the PC time has been elevated to administrative privileges and prioritizes clock security to flag clock tampering (jumps greater than 15 hours).

The first complexity a test engineer encounters is the hour that is duplicated then skipped every year when logging events based on local time due to daylight savings. If you want to calculate how many hours a durability test has been running, a simple (current time – start time) calculation would ideally suffice, but time jumps add complexity. Most environments have a datetime object that manages a lot of complexity of leap years, but your life is much easier if any timestamp uses Coordinated Universal Time (UTC). Python has a datetime.now(UTC) function, and .NET has DateTime.UtcNow().

Timekeeping is more complex than just daylight savings. If I had my way as a programmer, all computers would operate on TAI, or International Atomic Time. Over simplifying, TAI is the average of 450 atomic clocks around the planet counting cesium atoms oscillate without discontinuity since 1958. To keep the sun overhead at noon, leap seconds are added or subtracted from TAI to UTC. As of 2026, UTC is 37 seconds ahead of TAI. The last leap second was added in 2016. At the moment, the Earth’s rotation seems to be speeding up, so the first negative leap second is a possibility. There is discussion about freezing UTC and allowing solar noon to slip over time – something most computer operators should welcome. Leap seconds are a few orders of magnitude less impactful than an hour jump in local time due to daylight savings, but leap seconds are still a computing complexity when accurately calculating a duration.

Time transfer (synchronization) is generally accomplished based on global navigation satellite systems (GNSS) like the US GPS, EU Galileo, Russia’s GLONASS, or China’s BeiDou systems. Each GNSS system has its own epoch and rules. The GPS system has no leap seconds but a fixed 19 second offset between GPS time and TAI. Galileo time has a different zero (epoch) but keeps the same 19 second offset as GPS. Glonass and BeiDou both adjust to track UTC. Glonass offsets to Moscow’s timezone, and BeiDou makes small frequency adjustments to steer the clock in sync with UTC to avoid discontinuities.

A local time server in a lab is a small expense for the data coherence that accurate timestamps enable. If your lab is air-gapped (no internet connection), a time server on your lab LAN is essential. The CenterClick NTP270 (under $250) is my favorite GPS synced time server. Testing at SES indicates the ability to keep systems within 250 us (0.00025 s) of UTC across a LAN. The cleverly named TimeMachines TM2000B is under $600. The TM2000B lacks PoE power but has a temperature-controlled crystal that will hold time with loss of GPS much better than the NTP270. The TM2000B supports both NTP and Precision Time Protocol (PTP) (IEEE 1588). If your network switches are IEEE 1588 compliant (most are not), you can achieve <1us deviation across a LAN with PTP. If you have a five-figure budget, consider a GNSS disciplined Rubidium oscillator PTP GrandMaster like the Microchip Timeprovider 4500, MasterClock GMR6000, or Meinberg LANTIME PTP.

If nanosecond accuracy is insufficient, I presume you are an astro-physicist using your hydrogen MASERs between observatories and are part of a large and talented team beyond the scope of this BLOG.

I hope this wasn’t Too Much Information - Sincerely, Tom

Back to TMI Blog. . .