When is Timestamp Converter useful?
Timestamp conversion becomes important when a log, API, spreadsheet, and dashboard describe the same moment in different forms. Unix seconds are common in older APIs, JavaScript often uses milliseconds, and people usually want a readable date. This page keeps the unit visible so a value is not silently multiplied or divided by one thousand. It accepts a numeric timestamp or a browser-readable date, and it shows both a UTC result and a local-time comparison when the input is a timestamp.
The conversion rules are deliberately explicit. A seconds timestamp is multiplied by one thousand before the browser Date object reads it. A milliseconds timestamp is read directly. Auto-detection uses the size of the number, while the Unit menu lets you override that choice for unusual historical values. When a date is supplied, include Z or an offset if the source is not local time. The display timezone changes the text shown to you; it does not change the instant represented by the timestamp.
The common traps are a missing timezone, a rounded value, a seconds value passed to a milliseconds API, and a milliseconds value passed to a seconds API. An invalid date or unsafe numeric range is reported instead of producing a plausible but wrong answer. This page does not know the business timezone of a meeting or event, and it cannot correct a source that already lost its offset.
For debugging, compare the converted value with the original system documentation rather than with a second guess. A date-only string such as 2024-01-01 may be interpreted as UTC by the browser, while a date-time string without an offset can be interpreted as local time. The result therefore exposes both the selected display and the local comparison. If a service documents milliseconds, keep the Unit selector on milliseconds even when the value is short. If the service documents seconds, do not rely on a visual estimate of digit count. Copy the result only after checking the offset and unit against the receiving system.