Timestamp Converter

The Unix timestamp is the total number of seconds calculated from Coordinated Universal Time (UTC) January 1, 1970, 00:00:00, and this starting moment is called the "Unix Epoch." This design originated from the development of the Unix operating system in the 1970s, when developers needed a simple, unified way to represent time.

The greatest advantage of timestamps is timezone independence - it represents the same absolute moment anywhere in the world. Display differences across timezones are simply offsets added to or subtracted from the timestamp. This makes timestamps the ideal choice for database storage, API communication, and cross-timezone systems.

Traditional Unix timestamps have second-level precision, stored as 32-bit integers. But in scenarios requiring higher precision (such as JavaScript, Java), millisecond-level timestamps are used. The distinction is simple: 10 digits means seconds, 13 digits means milliseconds. In systems that mix different languages, this difference is a common source of bugs.

JavaScript Date.now() and Date.getTime() return millisecond timestamps. If you need seconds, you can convert with Math.floor(Date.now() / 1000). Conversely, converting seconds to milliseconds just requires multiplying by 1000. In API design, it is recommended to explicitly annotate the timestamp unit to avoid confusion.

Timestamps themselves have no timezone concept - they always represent UTC time. But when we convert a timestamp to human-readable date-time, we need to consider the timezone. For example, timestamp 1700000000 is 2023-11-14 22:13:20 in UTC, and 2023-11-15 06:13:20 in Beijing time (UTC+8).

A common mistake is treating local time directly as UTC time when calculating timestamps. The correct approach is to first convert local time to UTC, then calculate the timestamp. In JavaScript, the new Date() constructor automatically handles timezones, but toISOString() returns a UTC time string, while toLocaleString() returns a local time string.

The maximum value of a 32-bit signed integer is 2,147,483,647, corresponding to UTC time January 19, 2038, 03:14:07. Beyond this moment, second-level timestamps on 32-bit systems will experience integer overflow, potentially causing system crashes or incorrect time calculations. This is the famous "Year 2038 problem."

The solution is to migrate to 64-bit timestamps. On modern 64-bit operating systems, time_t is already 64-bit, theoretically capable of representing time up to over 292 billion years. However, some legacy systems, embedded devices, and older databases still use 32-bit timestamps and need to be upgraded before 2038. For web applications, JavaScript uses 64-bit floating-point numbers to store timestamps and is not affected by this limitation.

MySQL TIMESTAMP type internally uses Unix timestamps, with a range of 1970-2038 (32-bit limitation). The DATETIME type directly stores date-time strings, with a larger range but no automatic timezone conversion. In distributed systems, it is recommended to use BIGINT to store millisecond timestamps, which is neither limited by 2038 nor convenient for cross-timezone calculations.

MongoDB _id field embeds a 4-byte timestamp (millisecond-level), from which the creation time can be extracted from the ObjectId. Redis TTL is also calculated based on timestamps. When designing database schemas, the best practice is to uniformly use UTC timestamps for storage and convert to user timezones at the presentation layer.

JavaScript/TypeScript: Date.now() returns a millisecond timestamp, and new Date(timestamp) can convert a timestamp to a Date object. Note that JavaScript timestamps are in milliseconds, unlike most backend languages which use seconds.

Python: time.time() returns floating-point seconds, datetime.datetime.fromtimestamp() can convert to a date object. Java: System.currentTimeMillis() returns milliseconds, Instant.ofEpochSecond() handles seconds. Go: time.Now().Unix() returns seconds, time.Now().UnixMilli() returns milliseconds. Go 1.17+ added UnixMilli() and UnixMicro() methods. Understanding the differences across languages is crucial for cross-language API development.