A log entry contains 1792047600. A second system displays 1792047600000. A colleague sees 10:00, while another screen shows 07:00. These can all describe the same instant. The task is to establish the unit and display timezone before treating the difference as an error.

Use the BiNotePads Unix Timestamp Converter with a known example, then compare your source against it. Keep the original value beside the conversion so the source's assumptions remain visible.

Establish one unambiguous instant

Enter this value in Unix timestamp or date and select Process:

2026-10-15T07:00:00Z

The Z states that the supplied time is UTC. The live tool returned these values on October 15, 2026:

Unix seconds: 1792047600
Unix milliseconds: 1792047600000
ISO: 2026-10-15T07:00:00.000Z

In the browser used for that check, the Local line displayed 10:00 with an offset of GMT+0300. The local display depends on the browser's timezone. You should compare the ISO line when reproducing the test on a different device; your Local line does not need to look identical.

Next, process 1792047600 and 1792047600000 separately. Both returned the same ISO result in this test. This gives you three representations you can use to check an integration without relying on the current clock time.

Get the unit from the source

The difference between the two numeric values is a factor of 1,000. A Unix-seconds field counts seconds from the epoch. JavaScript's Date timestamp uses milliseconds; MDN's Date reference explains that representation and its UTC basis.

Do not choose a unit only because one conversion looks plausible. Check the API field description, export schema or application code responsible for the value. Names such as created_at do not establish a unit on their own.

BiNotePads uses a digit-length heuristic for numeric input: ten-digit values follow its seconds path, while longer accepted numeric values follow its milliseconds path. That works for the two values above. It is not a universal detector for every historical date, negative value or higher-precision timestamp. For unusual inputs, establish the unit outside this heuristic and supply an explicit ISO date when appropriate.

Separate the instant from its display

A timestamp identifies an instant. A timezone supplies the rules for displaying that instant as a local date and clock time. Changing the display zone should not change the underlying event.

This distinction is especially useful when comparing logs. Record the source value, source unit and UTC ISO result first. Add the local display as a separate field. Do not replace the original timestamp with a bare 10:00: the date and timezone information would disappear.

A reusable note for the example can look like this:

Source value: 1792047600
Source unit: seconds
UTC: 2026-10-15T07:00:00.000Z
Observed browser display: 2026-10-15 10:00, UTC+03:00

For real data, fill “Source unit” only after checking the originating system. Mark it unknown if the documentation is missing.

Avoid timezone-free deadlines

An input such as 2026-10-15T10:00 omits an offset. It can be interpreted as local time by a date-time parser, which leaves room for disagreement between devices. Use an explicit UTC value or an explicit offset when communicating a particular instant.

A recurring instruction such as “every morning at 10:00 in a named timezone” is a different requirement from a single timestamp. A date converter does not configure recurrence rules or resolve future local-time scheduling choices. Keep the schedule's timezone in the scheduling system rather than copying one example timestamp forward each day.

Before using a converted value, check that it refers to the intended field: creation time, update time and expiry time may all be valid timestamps with different meanings. A correct conversion cannot fix the selection of the wrong event.

Make a timestamp comparison reproducible

When someone reports that two screens show different event times, ask for the original machine-readable value from each screen's source and the documented unit. A screenshot of a clock label alone cannot distinguish a timezone difference from a different event or a delayed update.

Use a comparison note with four columns: event field, raw value, unit and UTC result. Compare the UTC results before comparing the local labels. If they match, inspect the display settings. If they differ, investigate the source fields and conversion assumptions before changing a timezone setting.

For an expiry bug, include the observation time separately from the expiry time. “Expired at 10:00” can otherwise mean either the stored deadline or the moment someone noticed the message. Naming both fields prevents an apparently precise timestamp from describing the wrong thing.

Keep precision visible as well. A seconds value does not tell you which millisecond within that second an event occurred. Multiplying it by 1,000 changes the unit but does not recover finer timing information. Avoid claiming that two events have a known order when the source precision cannot distinguish them.

Finally, record the explicit example used to test the converter. The fixed instant in this guide is more reproducible than a command to use the current time: another reader can compare the same numbers tomorrow without needing the clock from today's browser session.

Preserve the time information in a handover

When moving the conversion into a note or issue tracker, copy the explicit UTC result as text rather than retyping the local clock label from memory. Keep the raw input nearby and state what event it represents. If the conversion is being used to investigate a discrepancy, retain both original observations until the cause is understood. This makes the report useful to someone opening it in another timezone and avoids changing the evidence while trying to explain it.