Epoch timestamp converter

No. A Unix timestamp identifies an instant in time; it does not store time zone information. The same epoch timestamp can be displayed as different local dates and times depending on the time zone used to interpret it.

UTC defines the reference point for Unix time, but UTC is not an attribute embedded in each timestamp. Converting a timestamp to America/New_York, Europe/London, or UTC changes its human-readable representation, not the instant itself.

A date such as 2026-08-17 09:30:00 describes a local clock reading, not necessarily a unique instant. To convert it to a Unix timestamp, the converter needs one more piece of information: the time zone or UTC offset in which the clock reading occurred.

Without it, one must either assume a value, preserve it as an unspecified local time, or reject it as ambiguous. This is why two programs can produce different timestamps from the same otherwise valid date string if they use different default time zones.

When clocks move backward for daylight saving time, some local times occur twice. 01:30, for example, can refer to two different instants with different UTC offsets and therefore two different epoch timestamps. When clocks move forward, the reverse happens: some local times never occur at all.

Date-time libraries need a way to resolve this explicitly. C++20’s std::chrono, for example, provides std::chrono::choose::earliest and choose::latest so the caller can specify which instant a repeated local time refers to.

Epoch timestamps are useful when time needs to be stored or manipulated as a number. Comparing two timestamps, sorting them, or adding a duration is straightforward because each value is an offset from the same epoch.

ISO 8601 and its commonly used RFC 3339 profile are more descriptive and easier for people to understand. A value such as 2026-08-17T21:00:00-04:00 includes its UTC offset, although the offset still does not contain the full rules of a named time zone.

The unit is not encoded in the timestamp itself. Around present-day dates, digit count is a useful shortcut: Unix timestamps are typically 10 digits in seconds, 13 in milliseconds, 16 in microseconds, and 19 in nanoseconds.

That rule works because each step simply multiplies the same elapsed time by 1,000, but it is still a heuristic. Negative timestamps and sufficiently old or distant dates can have different lengths.

For exact timestamps, integers are usually the safest representation: store a whole number of seconds, milliseconds, microseconds, or nanoseconds and keep the unit explicit. Floating-point seconds are convenient, but they cannot preserve arbitrarily fine subsecond values as the timestamp grows.

For example, an IEEE 754 binary64 value around the current Unix epoch has representable values about 238 nanoseconds apart. Representing a present-day timestamp to the nanosecond requires about 19 significant decimal digits, and binary64 carries roughly 15 to 17. The type cannot represent every possible nanosecond.

A signed 32-bit integer can represent values only up to 2,147,483,647. If that integer is interpreted as seconds since the Unix epoch, the maximum timestamp corresponds to January 19, 2038 at 03:14:07 UTC. Incrementing it again overflows the signed 32-bit range.

This is the Year 2038 problem, or Y2038. Modern systems commonly use wider time representations, but the limit can still matter in legacy software, embedded systems, file formats, and interfaces that retain 32-bit timestamp fields.

Accuracy describes how closely a timestamp agrees with its intended reference time, usually UTC. Precision describes how closely repeated measurements or synchronized clocks agree with one another. In timekeeping, a clock can therefore be very precise yet inaccurate—for example, consistently reporting a time two milliseconds behind UTC.

A timestamp can have nanosecond precision but still be milliseconds away from UTC if the clock is poorly synchronized. Conversely, a clock can be closely synchronized to UTC but only record time to millisecond precision.

No. Resolution only describes the smallest increment the representation can express. A timestamp field may count in one-nanosecond increments, while the actual time assigned to an event is uncertain by hundreds or thousands of nanoseconds.

Accuracy and precision depend on how the timestamp is produced. Software timestamping can introduce variable delays due to interrupts, scheduling, context switches, and the networking stack. Hardware timestamping captures time closer to the actual event and removes much of that variability. Put differently, nanosecond resolution is a property of the representation; nanosecond accuracy is a property of the measurement system.

A computer clock is ultimately driven by an oscillator, and no two oscillators run at exactly the same rate. Setting two clocks to the same value once is therefore not enough—they will begin drifting apart again. Time synchronization continually estimates the difference from a reference clock and corrects it. Closely related is syntonization, which adjusts clocks so their oscillators advance at the same rate.

NTP and PTP both exchange timestamped messages to estimate clock offset and network delay. A simple way to think about it is to ask another clock what time it is, then account for how long it took for the answer to reach you. The difficult part is that outbound and return paths do not always take the same amount of time. If the path is asymmetric, estimating the one-way delay as half the round-trip time introduces clock error.

PTP is designed for highly accurate synchronization on controlled local networks and commonly uses hardware timestamps plus PTP-aware switches or routers that can account for time spent forwarding packets. NTP is far more common for general-purpose synchronization and is often implemented in software rather than hardware.

Sometimes, but the subtraction is only meaningful if the timestamps are comparable. They need to represent the intended start and end events, and the clocks that produced them need to be synchronized closely enough for the latency being measured.

If both timestamps come from the same clock, clock synchronization is largely removed from the subtraction. If they come from different machines, any clock offset between them contributes to the measured latency. A five-microsecond measurement is not very useful if the clocks producing it can disagree by a millisecond. The synchronization uncertainty needs to be comfortably smaller than the interval you are trying to measure.

For ordinary clock synchronization, Google Public NTP, NIST, Cloudflare Time, and NTP Pool are all reasonable defaults. The practical differences between them are fairly minor, and for most applications, the network path to the server matters more than the provider itself.

Trading is a more specialized case, where proximity to the clock source and consistency with market data timestamps can matter. Databento’s free NTP service runs stratum 1 servers in Equinix NY4 and CyrusOne Aurora I, synchronized to the same PTP source used for its market data timestamps. It was launched as the first public NTP service specifically housed in financial data centers, making it particularly useful for trading systems in New York/New Jersey and Chicago.

Leap years affect the calendar date represented by a timestamp, but not how Unix time itself is counted. POSIX time treats every day as exactly 86,400 seconds; a leap year simply adds February 29 as another 86,400-second day.

That distinction is useful when doing date arithmetic. From February 28 to March 1 is one day in a normal year but two days in a leap year, so the corresponding Unix timestamps differ by 86,400 or 172,800 seconds. Unlike leap seconds, leap years follow deterministic Gregorian-calendar rules and can be calculated arbitrarily far in advance.

Leap seconds exist because atomic time and the Earth’s rotation do not stay perfectly aligned. International Atomic Time (TAI) is a continuous time scale derived from atomic clocks. UTC advances at the same rate, but has historically been adjusted by whole seconds to keep it close to UT1, which tracks the Earth’s rotation. TAI is currently 37 seconds ahead of UTC.

Unix/POSIX time avoids representing those extra seconds directly: every day is treated as exactly 86,400 seconds, so 23:59:60 has no distinct Unix timestamp. Systems therefore need a policy for handling a leap second. Some step or repeat the clock; others use a leap smear, running the clock slightly faster or slower over a defined window so the extra second is absorbed gradually. Google uses a 24-hour linear smear, while Bloomberg divided the 2016 leap second across the following 2,000 seconds.

Because there is no universal policy, clocks using different methodologies can temporarily disagree. Cloudflare’s 2017 DNS incident, for example, was ultimately caused by software assuming wall-clock time could never move backward.

For systems requiring tighter synchronization—such as those in financial markets—PTP with hardware timestamping is common. Databento, for example, uses PTP across its stack, with pairs of GPS-backed grandmaster clocks accurate to under 25 nanoseconds against UTC and data servers synchronized to those clocks within a microsecond.

Fortunately, leap seconds are being phased out. In 2022, the CGPM decided that the permitted difference between UT1 and UTC will be increased by or before 2035, allowing UTC to remain continuous for at least a century rather than periodically inserting leap seconds.