Milliseconds to date: UTC vs local time, and why it can look off

Last reviewed 2026-05-05. The free milliseconds-to-date converter takes a Unix millisecond timestamp and returns a readable date and time. Most reader confusion is not about the conversion itself - it is about which timezone the readable string represents. This guide names the four values you should always read together and gives a 30-second sanity check so you never ship a date that is hours off.

Why the same timestamp shows different dates

A Unix millisecond timestamp counts the milliseconds elapsed since the Unix epoch, fixed at 1970-01-01T00:00:00 UTC. The number does not carry a timezone or a calendar. Every system that displays it picks its own timezone for the human-readable output: your browser uses the OS locale, a server uses its container's locale, a SQL database uses its session timezone, and a JSON log uses whatever the writer formatted with. The millisecond-to-date converter shows both UTC and your local time so you can see the offset at a glance.

The four values to always read together

• The original number (1713538800000) - timezone-free. Store this in databases, send it across HTTP APIs, log it. It never drifts.
• UTC date/time (2024-04-19T15:00:00Z) - the canonical render. Use it in audit logs, cross-region reports, and anything shared across teams.
• Local date/time (2024-04-19 22:00:00 +07:00) - what the end user sees. Use it for emails, calendar invites, and reader-facing displays.
• ISO 8601 with offset (2024-04-19T22:00:00+07:00) - round-trip-safe. Includes wall-clock and offset, so a downstream parser can recover the exact moment.

30-second sanity check before shipping a date

1. Confirm the input is in milliseconds, not seconds. A 13-digit number is milliseconds; a 10-digit number is seconds. See long number - millisecond or second? for the rules.
2. Note the UTC value the converter returns. This is the canonical, timezone-free answer.
3. Add the local offset to UTC (e.g. +07:00 for Bangkok, -08:00 for Los Angeles, with daylight-saving). The local value should match.
4. If the local value disagrees, your OS timezone is set differently than you assumed. Adjust the OS or interpret UTC directly.

UTC vs local in practice

Use UTC for storage and transport. Database columns, JSON over HTTP, log files, audit trails. UTC values do not drift across daylight-saving transitions and do not vary by deployment region.

Use local time only for display. Calendar invites, user-facing emails, reminders. Convert to local at the rendering layer, not in storage. The same database row should render as 22:00 Bangkok time and 08:00 LA time - that is correct, not a bug.

Use ISO 8601 with offset for the in-between cases. When you send a value to a downstream system that may not know the user's timezone, prefer the offset-included ISO form. Avoid free-text "April 19 at 10 PM" - it is unparseable.

Companion guides

• Long number - millisecond or second? - input disambiguation.
• Unix timestamps explained - what the epoch is and where the format comes from.
• Milliseconds to date converter - the tool itself.
• Get current time in milliseconds - the inverse direction.

Frequently asked questions

Why does the converter show two different times for the same input?
They are the same instant in different timezones. The number is timezone-free; the UTC value is the canonical render and the local value is the same instant viewed from your OS timezone. The difference is the local offset.

The local time looks wrong - how do I fix it?
The local time is whatever your OS reports as the current timezone. If your laptop is set to Singapore but you expect Bangkok, the local value will be one hour off. Adjust the OS timezone, or interpret the UTC value and apply the offset you actually want.

Does daylight saving change the conversion?
Yes - for any timezone that observes DST, the local offset shifts by one hour twice a year. The UTC value never changes. Two timestamps from opposite sides of a DST boundary look one hour apart in local time even when the elapsed milliseconds are correct.

Can I store local time directly in my database?
Yes, but rarely a good idea. Storing UTC and rendering local at the read site is canonical; it survives server moves, region changes, and DST transitions. Storing local time forces every reader to know which timezone the writer was in - usually lost.

Is anything sent to a server?
The conversion runs in your browser; the millisecond input and the resulting strings stay on your device. This matters when the timestamp identifies a sensitive event you do not want to log.