Introduction

Converting an integer timestamp into a datetime is simple once you answer two questions first: what unit the timestamp uses, and which time zone you want the result in. Most conversion bugs come from mixing up seconds and milliseconds or from silently converting to local time when the timestamp was meant to stay in UTC.

Identify the Timestamp Unit First

Many systems store Unix timestamps, which count time from 1970-01-01 00:00:00 UTC. The tricky part is that some systems store seconds, while others store milliseconds.

For example:

• '1704067200 usually means seconds'
• '1704067200000 usually means milliseconds'

If you treat milliseconds as seconds, the result lands thousands of years in the future. If you treat seconds as milliseconds, the result lands near the Unix epoch. So unit detection is not optional.

Convert in Python

Python's datetime module handles both cases cleanly. Use a timezone-aware conversion when possible so the result is explicit.

1from datetime import datetime, timezone
2
3timestamp_seconds = 1704067200
4timestamp_milliseconds = 1704067200000
5
6dt_utc_from_seconds = datetime.fromtimestamp(timestamp_seconds, tz=timezone.utc)
7dt_utc_from_milliseconds = datetime.fromtimestamp(
8    timestamp_milliseconds / 1000,
9    tz=timezone.utc,
10)
11
12print(dt_utc_from_seconds.isoformat())
13print(dt_utc_from_milliseconds.isoformat())

If you want local time instead of UTC, pass the desired time zone rather than dropping the time zone information entirely.

Convert in JavaScript

JavaScript Date expects milliseconds since the Unix epoch, so the unit rule is reversed from many backend examples.

1const timestampMs = 1704067200000;
2const timestampSeconds = 1704067200;
3
4console.log(new Date(timestampMs).toISOString());
5console.log(new Date(timestampSeconds * 1000).toISOString());

If your API returns seconds, multiply by 1000 before building the Date. If it already returns milliseconds, pass the value directly.

Choose UTC or Local Time Deliberately

An integer timestamp is usually time-zone neutral until you format it for display. The same moment can be shown as UTC, Toronto time, Tokyo time, or any other zone. That means conversion is not just parsing. It also includes choosing how the result should be represented.

In Python, datetime.fromtimestamp(..., tz=timezone.utc) creates an aware UTC datetime. In JavaScript, toISOString() also renders UTC. If you instead print a local representation, the calendar date and clock time may change even though the underlying instant is the same.

That difference matters in logs, billing windows, and user-facing reports.

Handle Databases and APIs Carefully

Databases and APIs often serialize timestamps as integers because they are compact and language-neutral. When you read them back:

• confirm whether the integer is in seconds, milliseconds, or microseconds
• confirm whether the producer expects UTC or local display
• keep the conversion close to the boundary where the data enters your system

Doing this early avoids a whole category of subtle bugs where some layers use naive datetimes and others use explicit UTC values.

Common Pitfalls

• Confusing seconds with milliseconds. This is the most common conversion bug by far.
• Creating naive datetime objects in one part of the application and timezone-aware ones in another.
• Assuming the displayed local clock time is the original stored value. The integer timestamp represents an instant, not a formatted string.
• Forgetting that JavaScript Date expects milliseconds, not seconds.
• Formatting a timestamp for humans before deciding which time zone the user actually needs to see.

Summary

• Determine the timestamp unit before converting it.
• Use timezone-aware conversions so the result is explicit and less error-prone.
• In Python, convert seconds directly and divide milliseconds by 1000.
• In JavaScript, pass milliseconds directly and multiply seconds by 1000.
• Treat time zone choice as part of the conversion, not as an afterthought.