Seconds or milliseconds: diagnose a timestamp that lands in 1970

Choose an event whose date is already known

A test export says an event occurred at the start of 2024, but a viewer shows January 1970. Before changing the timezone, check the numeric unit. Unix seconds and Unix milliseconds describe the same epoch with different scales. A value in seconds interpreted as milliseconds is one thousandth of the intended elapsed time.

Use the synthetic midnight-UTC event below as an anchor. KitForma Timestamp Converter has explicit seconds and milliseconds modes. Enter the first value in seconds mode and the second in milliseconds mode; both should produce the same UTC date. Do not run a mass repair until that small comparison works.

Unix seconds:      1704067200
Unix milliseconds: 1704067200000
Expected UTC: 2024-01-01T00:00:00.000Z

MDN: JavaScript Date timestamps ↗

Make the wrong-unit result visible

Now enter 1704067200 in milliseconds mode. The result is 1970-01-20T17:21:07.200Z. That deliberately wrong result explains the symptom without blaming the clock on the viewer’s device. A timezone offset cannot repair a thousandfold unit mismatch.

Ten-digit and thirteen-digit values are familiar for many contemporary timestamps, but length is not a universal detector. Earlier dates, negative values, fractional seconds, microseconds and application-specific epochs break that shortcut. Read the field documentation or obtain a known source event before choosing the scale.

1704067200 interpreted as milliseconds:
1970-01-20T17:21:07.200Z

Do not label this as a timezone-only problem.

Record the precision that the destination can retain

The current KitForma converter reports UTC, Unix seconds and Unix milliseconds. Its conversion rounds to the nearest millisecond. It is useful for inspection at that precision, but it is not an archive for nanosecond event data. Keep the original numeric text if smaller units or exact fractional values matter.

For an ISO input, use an explicit Z or numeric UTC offset when supplying a time. In this tool, a date-only input means UTC midnight; that does not establish the producer’s business timezone. Avoid adding Z to a local wall-clock value unless the source really defines it as UTC.

1. Record field name, epoch, unit, timezone rule and precision.
2. Test a known event before changing the column.
3. Convert into a new field, preserving the raw value.
4. Compare the earliest, latest and one middle event.
5. Check negative and fractional values if the contract permits them.

RFC 3339: timestamps and UTC offsets ↗

Use an explicit field name in the repaired export

Names such as event_time_unix_ms and event_time_utc make the chosen representation clearer than date2. Record the conversion factor and any rounding in the handover. A downstream team should not have to infer the unit again from sample values.

If different producers used different units in one column, do not multiply the whole column by one thousand. Separate records by a trustworthy source or schema version and flag ambiguous rows. A successful conversion is not proof that the original timestamp represents the intended business event.

Q: Should I add my local offset to a Unix timestamp?

No for a normal Unix timestamp representing an instant. Keep the numeric instant and choose the timezone only when displaying it. If the source stored a local wall-clock value incorrectly, resolve that source convention before applying a correction.

Q: Is every 13-digit number a millisecond timestamp?

No. It could be an identifier or a timestamp under another convention. Validate the field contract and a known date; never convert an entire identifier column solely because its values have a familiar length.