Timestamps are the one piece of time data every machine agrees on, and the one everybody misreads. A log line, a database column and an API payload all agree on what 1757000000 means - an exact instant, counted in seconds since the epoch - and almost every bug in this area comes from something the timestamp does not contain. It has no time zone, because it does not need one. It has no month name, no weekday, no offset, and no idea whether you meant seconds or milliseconds. It does not even have a leap second in it: Unix time counts seconds without them, which is why published tables of Unix time and UTC occasionally disagree by a second. This page links out to EpochConverter, a reference site that has been online for a long time, and the notes below cover the mismatches that actually cause incidents.
Seconds, milliseconds, and the 13-digit mistake
Count the digits. A ten digit value is seconds, a thirteen digit value is milliseconds, and a sixteen or nineteen digit value is usually microseconds or nanoseconds. The number 1757000000 means September 2025 in seconds and January 1970 in milliseconds, which is a difference of roughly fifty-six years and produces the classic 1970 date in every dashboard ever built. The reverse error is just as common: a field documented as milliseconds receives seconds, and the date renders as some year in the far future. Language defaults differ, which is where the confusion starts - JavaScript's Date.now and Java's System.currentTimeMillis are milliseconds, PHP's time is seconds, Go mixes depending on whether you call Unix or UnixNano, and a Unix command line tool usually wants seconds with an explicit at sign. Passing the wrong unit to a tool does not produce an error message. It produces a plausible date.
Time zones and the two moments a timestamp cannot express
A Unix timestamp is an absolute instant with no zone attached, so anything that displays it has to choose one, and every display choice is a decision you can get wrong. The two genuinely impossible cases are both about daylight saving. In spring, a local wall-clock time in the gap simply never occurs - in a European zone, 02:30 on the transition Sunday does not exist, and formatting a timestamp into that hour produces a time that was never a real moment. In autumn, a wall-clock time occurs twice, so a timestamp alone cannot tell you which of the two passes you meant. JavaScript has one more trap worth knowing: a date-only string such as 2026-03-01 is parsed as UTC, while a date and time string without a zone such as 2026-03-01 10:00 is parsed as local time. Identical looking strings, two different instants, and a bug that only shows up on a colleague's laptop.
When a one-liner is the better answer
A converter earns its keep when you are reading something you did not write: a log, an export, someone else's documentation. For your own scripts, the shell is faster and never ambiguous. On GNU coreutils, date -u -d @1757000000 prints the instant; on macOS and BSD the same job is date -u -r 1757000000, and mixing them up produces a confusing error because the two systems use opposite flags. In Python, datetime.datetime.fromtimestamp(1757000000, tz=datetime.timezone.utc) keeps the zone explicit, and in JavaScript new Date(1757000000 * 1000).toISOString() gives a UTC string that sorts correctly and round trips. A rule that saves time: decide and state the unit and the zone before converting anything, and write both into the log line next to the value. Most timestamp incidents are really zone or unit incidents, and a suffix like _ms or an explicit Z would have prevented them.
Frequently asked questions
Are the timestamps shown in my local time zone?
The page shows the instant in whatever zone you select, and the epoch value itself has no zone attached - that is the point of it. Pick UTC when you are comparing machines or reading a log, and pick a city when you are telling a person when something happened. Note that a laptop which travels will show different values for the same timestamp depending on where it is at the time.
Where does the epoch start?
Unix time counts seconds from 1970-01-01T00:00:00Z, which is midnight UTC on the first of January 1970. Times before that are negative values. The system is named after the Unix operating system, where the convention was adopted, and it deliberately ignores leap seconds, so the count is not an exact count of SI seconds.
Why is my timestamp eight hours off from the server log?
That difference is almost always a time zone offset, and the server is very likely storing and logging UTC while the tool is rendering your local time. Check by converting the value with an explicit UTC selector: if it then matches the log line, the timestamps are fine and only the display differed. An offset that is not a whole number of hours is a daylight saving problem instead.
Is this tool free, and do I need to install anything?
The service this page links to is free, and so is everything on this site. It runs in your browser, which is convenient when you are reading a timestamp out of a log window. If you find yourself converting timestamps all day, a single shell alias will be faster than a web page.