The timestamp converter that tells you what you're looking at

The 1970 date bug: when a 13-digit timestamp is read as seconds

The most common failure we kept hitting during build was the inverse of the year-49,995 case. A logging pipeline emits 13-digit millisecond timestamps. A downstream parser, written against an older API contract, reads the value as seconds. The result isn't a year-49,995 garbage date. It's a plausible date 1,000 times in the future, which gets quietly truncated by a database column that won't accept it. The row lands with a NULL or, worse, with the maximum timestamp the column supports, often December 31, 9999.

The reverse case is louder. Strip a 13-digit value down to 10 digits (sloppy substring, a regex that captured too little, a CSV cell that hit a column width limit) and feed it as seconds. The first 10 digits of 1711987200000 give 1711987200, March 2024. Benign. But 1700000 (a truncated value pasted out of a broken log entry) reads as January 20, 1970 at 14:13:20 UTC. Now every event in your system happened during the moon-shot era.

How do you tell which side of this bug you're on?

Look at the year. If your date is in the future or past 2286, the input was milliseconds parsed as seconds. If your date sits in 1970, the input was a stripped-down value that should have been longer. In our build we chose to make the detected unit visible as a badge above the result so the user catches the mismatch in the first second, not after a deploy.

The year 49,995 problem: the silent overflow nobody notices

This failure mode hides in test fixtures. A unit test pins a "future date" with a millisecond timestamp because that's what the app emits. A separate service reads the fixture as seconds. The test passes because both sides are wrong in the same direction. Production breaks the moment a real user record routes through one service but not the other.

Epochr's defense sits in the decision table below. We tested every digit count from 9 through 20 against actual outputs from Node 22, Python 3.13, Go 1.24, and Postgres 17 to build it. The table is the contract: count, identify, then parse.

The "read as seconds gives" column shows the lie a naive converter tells. Epochr refuses to compute that column at all unless the user explicitly overrides the detected unit. The override exists for one case: a 10-digit microsecond value emitted by a system that pre-divides by a million. We have seen it once, in a Kafka topic from a payments processor we won't name.

Microseconds in PostgreSQL: why timestamptz columns produce 16-digit values

This pattern shows up across older Postgres apps that want sub-millisecond resolution without timestamptz directly:

SELECT extract(epoch FROM now()) * 1000000;
-- returns: 1711987200123456

The output is a 16-digit integer. Newer apps store timestamptz natively and convert at query time, which is correct but produces output strings rather than integers, so the 16-digit form survives in logs, message queues, and analytics pipelines.

The Date object loses precision on conversion. JavaScript's Date works at millisecond resolution; nothing past three decimal places after the comma survives. Epochr reports the full 16-digit input in the badge but renders the date at millisecond resolution, with the dropped microseconds shown in a smaller annotation. The failure mode we kept hitting was rounding: dividing by 1,000 before constructing a Date introduces a half-millisecond bias on average. We round to nearest, not toward zero, which matches what Postgres's own to_timestamp(microseconds / 1000000.0) does.

Nanoseconds in Go: time.UnixNano() and the precision you lose on conversion

Go's time.UnixNano() returns an int64 of nanoseconds since the epoch:

t := time.Now().UnixNano()
// e.g. 1711987200123456789

The value runs 19 digits for any timestamp between 2001 and 2262. After 2262 the int64 overflows: Go's documented "year 2262 problem," analogous to the year 2038 problem for 32-bit second timestamps.

JavaScript can hold the full 19-digit value in a BigInt but cannot hand it to Date, which is double-precision float and tops out at the year 275,760. Epochr takes the only sensible path: divide by a million to reach milliseconds, store the lost six digits separately, and report them in the output. Those dropped digits aren't noise. In a distributed tracing context they're the difference between two spans landing in the right order and showing up as simultaneous.

DST and the one-hour ambiguity that breaks fall-back timestamps

On the morning the clock falls back, every local-time string between 1:00 AM and 2:00 AM happens twice. A timestamp like "2025-11-02T01:30:00 America/New_York" is truly ambiguous: it could be EDT (UTC-4) or EST (UTC-5). The two readings sit an hour apart in Unix-epoch terms.

Browsers default to "earlier" via the Intl engine, which picks the EDT reading. Postgres defaults to "earlier" too. Python's datetime.replace(tzinfo=...) does whatever you tell it, which means nothing useful by default. We surface the ambiguity in epochr by parsing both readings and showing the gap when the input is a local-time string in a fall-back window. The result: two timestamps with a one-hour delta and a note about which one the runtime picked.

Negative timestamps: Unix times before January 1, 1970

-2208988800 is the Unix timestamp for January 1, 1900. Negative values are legal in POSIX and supported by time.Time in Go and JavaScript's Date. Not every database driver agrees. SQLite stores them fine; older MySQL versions reject them outright; some ORMs silently clamp at zero. The clamp is the dangerous one.

Birthdays before 1970 are the most common real input. Historical event timestamps show up in archival contexts. Epochr accepts negative values across all four units, with the same digit-count rule applied to the absolute value: a 10-digit negative number is still seconds, a 13-digit negative number is still milliseconds.

Inline questions worth a closing pass

Does epochr work offline?

Yes. Every conversion runs in the browser via the Date and Intl APIs. After the first page load the tool works with no network connection. The Service Worker is not aggressive (we kept it minimal to avoid stale-state bugs across timezone updates), but the converter itself is pure JavaScript and works without a server round-trip.

What about the year 2038 problem?

The 2038 problem is specific to 32-bit signed integer seconds. Epochr's internal representation uses JavaScript's double-precision float milliseconds, good through the year 275,760. The 2038 boundary is still visible in input data, though: a 10-digit timestamp from a C program compiled against a 32-bit time_t will wrap to 1901 on January 19, 2038. We flag values close to the boundary in the badge.