Unix timestamps: the number in your logs that everyone guesses at

Somewhere in your logs right now there is a line like created_at: 1766400000. Somebody on the team is converting it by typing "unix timestamp converter" into a search engine, picking the first result, and pasting your operational data into an ad-covered page of unknown provenance.

Why epoch numbers refuse to die

Unix time counts seconds since 1970-01-01 UTC. It survives because it is unambiguous: no timezones, no locale formats, no two-digit-year nonsense. Databases store it, APIs emit it, cron systems speak it. The cost is that humans cannot read it, so every debugging session touches a conversion.

Conversions that come up more than you expect

• Milliseconds versus seconds. JavaScript's Date.now() gives milliseconds; most backend systems give seconds. A 13-digit number is milliseconds, 10 digits is seconds. Off-by-1000x bugs in date filters usually trace back to mixing these.
• Timezone handoff. A timestamp is absolute; the timezone is a presentation choice. When a bug report says "the reminder fired at the wrong time," the epoch number in the log is usually right and the rendering is what is wrong. Convert the raw number first, then argue about display.
• Future timestamps. A subscription's expires_at as a raw epoch value tells you instantly whether it is in the past without trusting server-local time.

A decent unix time converter does both directions and shows the result in UTC and your local zone, because the two answers differ and both matter. Pair it with a timezone converter when the question is "what does 09:00 in Riga mean for a server in UTC" rather than "what is this number."

The date math people get wrong

"Thirty days before launch" sounds easy until the window crosses a DST transition, a leap day, or a month boundary. Counting days between dates by hand in a spreadsheet is where off-by-one errors breed. The date difference tool settles it in one paste, including inclusive versus exclusive counting, which is the argument nobody realizes they are having until the calendar reminder fires a day late.

One habit to steal

When you read a timestamp in a log, convert it before you theorize. Half of "the job ran at the wrong time" incidents dissolve once the raw number says 03:00 UTC and the person reporting remembers the client is in a different zone. Two seconds with a converter beats twenty minutes of timezone archaeology in a codebase you barely remember writing.