Timestamps seem simple — just a number, right? But I have seen many developers trip over them. Including myself.
Once, I was building a backend API for an app. I returned timestamps in milliseconds (13 digits), but the frontend developer assumed they were seconds (10 digits) and divided by 1000. Every date in the app showed as January 1, 1970. Users were confused, and complaints poured in.
After that incident, I now annotate every API with "timestamp unit: milliseconds," and both sides confirm using a timestamp converter before integration. It sounds excessive, but it has prevented similar issues.
Seconds vs milliseconds
Timestamps come in two common formats: 10-digit (seconds since 1970-01-01, used by PHP's time()) and 13-digit (milliseconds, used by JavaScript's Date.now()).
How to tell them apart? Count the digits. 10 digits = seconds, 13 digits = milliseconds. If unsure, paste into our Timestamp Converter — it auto-detects.
Timezone and timestamps
Timestamps themselves are timezone-independent. They represent the same instant everywhere. But the readable date depends on your timezone. For example, timestamp 0 is 1970-01-01 08:00:00 in Beijing, but 1970-01-01 00:00:00 in London.
The rule: store and transmit timestamps in UTC (they already are), convert to local time only when displaying to users.
The Year 2038 problem
32-bit signed integers max out at 2147483647 — January 19, 2038. This is the "Year 2038 problem." Most modern systems use 64-bit integers and are safe, but embedded systems and legacy databases may still be vulnerable.
Good news: PHP 5.2+ supports 64-bit timestamps. But if you are maintaining legacy systems, it is worth checking.
Use our tool
I keep our Timestamp Converter open in a browser tab during development. Every time I encounter a timestamp, I verify it — seconds or milliseconds, is the date correct? This habit has prevented at least 5-6 production incidents.