Convert a Unix timestamp to a date

Seconds or milliseconds

Unix time is defined in seconds, but JavaScript's Date.now() returns milliseconds, and so do many APIs and log formats built on it. The two are told apart by length: a ten-digit number is seconds, a thirteen-digit number is milliseconds.

Feeding milliseconds to a seconds parser produces a date tens of thousands of years in the future, which at least announces the mistake. The reverse is quieter: seconds parsed as milliseconds land in January 1970 and look like a zero value or an uninitialised field.

Time zones are where the real errors are

A Unix timestamp has no time zone. It is an absolute instant, and every conversion to a human-readable date applies one. Two people reading the same log line in different countries will legitimately see different local times.

That is why incident timelines should be written in UTC, and why a converter should show both — your local time for reading, UTC for anything you are going to share.

The 2038 problem, briefly

A signed 32-bit timestamp overflows on 19 January 2038. Modern systems use 64-bit values and are unaffected, but the limit still appears in old embedded systems, some database columns, and file formats that were fixed decades ago. A date near 1901 in the output usually means an overflow rather than a real value.

2147483647  →  2038-01-19 03:14:07 UTC

The largest value a signed 32-bit timestamp can hold.

How to check the claim rather than trust it

Bellows is signed without a network entitlement. That is not a policy someone wrote down — it is a permission the binary does not have, and macOS enforces it whether the app wants to connect or not. You can read the entitlements it was signed with:

codesign -d --entitlements - /Applications/Bellows.app

Neither com.apple.security.network.client nor com.apple.security.network.server appears in the output. Without them the sandbox refuses to open a socket.