Convert Timestamps Online

Use our free timestamp converter to convert between Unix, ISO 8601, and human-readable formats.

Open Timestamp Converter →

Understanding Unix Timestamps

A Unix timestamp (also known as Epoch time or POSIX time) represents the number of seconds that have elapsed since January 1, 1970, 00:00:00 UTC. This moment is called the "Unix Epoch."

// Current Unix timestamp in seconds
Math.floor(Date.now() / 1000) // e.g., 1733836800 // Current Unix timestamp in milliseconds
Date.now() // e.g., 1733836800000 // Convert timestamp to Date
new Date(1733836800 * 1000) // Tue Dec 10 2024... // Convert Date to timestamp
Math.floor(new Date('2024-12-10').getTime() / 1000)

Seconds vs Milliseconds

JavaScript's Date.now() returns milliseconds, but most Unix timestamps are in seconds. Always check what format you're working with! A 10-digit number is seconds; a 13-digit number is milliseconds.

ISO 8601: The Universal Standard

ISO 8601 is an international standard for date and time representation. It's unambiguous, sortable, and widely supported across programming languages.

ISO 8601 Formats

// Full date and time with timezone
2024-12-10T15:30:00Z // UTC (Z = Zulu time)
2024-12-10T15:30:00+05:30 // With timezone offset
2024-12-10T15:30:00.123Z // With milliseconds // Date only
2024-12-10 // Time only
15:30:00
15:30:00.123 // Week format
2024-W50 // Week 50 of 2024
2024-W50-2 // Tuesday of week 50 // Duration format
P1Y2M3DT4H5M6S // 1 year, 2 months, 3 days, 4 hours, 5 min, 6 sec

JavaScript ISO 8601 Handling

// Get ISO string from Date
new Date().toISOString() // "2024-12-10T15:30:00.000Z" // Parse ISO string
new Date('2024-12-10T15:30:00Z') // Tue Dec 10 2024... // Important: Parsing without 'Z' assumes local timezone!
new Date('2024-12-10T15:30:00') // Interpreted as local time
new Date('2024-12-10T15:30:00Z') // Interpreted as UTC

Time Zone Handling

Time zones are one of the most common sources of bugs in software. Here's how to handle them correctly:

✅ Best Practices

  • Store all timestamps in UTC
  • Convert to local time only for display
  • Use ISO 8601 for API communication
  • Include timezone info in user-facing dates
  • Test with multiple timezones

❌ Common Mistakes

  • Storing local times without timezone
  • Assuming server timezone matches user's
  • Ignoring daylight saving time
  • Using date-only strings for timestamps
  • Manual timezone calculations

Modern Time Zone API

// Get user's timezone
Intl.DateTimeFormat().resolvedOptions().timeZone // "America/New_York" // Format date in specific timezone
new Date().toLocaleString('en-US', { timeZone: 'Asia/Tokyo', dateStyle: 'full', timeStyle: 'long'
})
// "Tuesday, December 10, 2024 at 12:30:00 AM JST" // Convert between timezones
function convertTimezone(date, fromTz, toTz) { return new Date(date.toLocaleString('en-US', { timeZone: toTz }));
}

Common Conversion Formulas

FromToFormula
Unix (s)Unix (ms)timestamp * 1000
Unix (ms)Unix (s)Math.floor(timestamp / 1000)
Unix (s)Datenew Date(timestamp * 1000)
DateUnix (s)Math.floor(date.getTime() / 1000)
DateISO 8601date.toISOString()
ISO 8601Datenew Date(isoString)

Database Timestamp Types

Different databases handle timestamps differently:

-- PostgreSQL
TIMESTAMP -- No timezone, stores as-is
TIMESTAMP WITH TIME ZONE -- Converts to UTC for storage
TIMESTAMPTZ -- Alias for TIMESTAMP WITH TIME ZONE -- MySQL
DATETIME -- No timezone, 8 bytes
TIMESTAMP -- Converts to UTC, 4 bytes, Y2038 issue -- SQLite
TEXT -- Store as ISO 8601 string
INTEGER -- Store as Unix timestamp
REAL -- Store as Julian day number

The Year 2038 Problem

32-bit Unix timestamps will overflow on January 19, 2038, at 03:14:07 UTC. This is similar to the Y2K bug. Modern systems use 64-bit timestamps, which won't overflow for billions of years.

// Maximum 32-bit Unix timestamp
2147483647 // Tue Jan 19 2038 03:14:07 UTC // Maximum 64-bit Unix timestamp 9223372036854775807 // ~292 billion years from now

Frequently Asked Questions

Why use Unix timestamps instead of formatted dates?

Unix timestamps are timezone-agnostic, easy to compare and sort, compact for storage, and avoid ambiguous date formats (is 01/02/03 January 2nd or February 1st?).

How do I handle daylight saving time?

Store times in UTC and convert to local time for display. Use libraries like date-fns-tz or Luxon that understand DST rules. Never calculate timezone offsets manually—they change based on date.

Should I use seconds or milliseconds?

Use seconds for storage and APIs (more compact, widely understood). Use milliseconds when you need sub-second precision or when working with JavaScript Date objects.

  • date-fns: Modern, modular, tree-shakeable date library
  • Luxon: Powerful timezone handling, successor to Moment.js
  • Day.js: Lightweight Moment.js alternative
  • Temporal (upcoming): New JavaScript standard for dates/times

Conclusion

Timestamps seem simple but hide complexity in time zones, formats, and edge cases. By storing in UTC, using ISO 8601 for communication, and being explicit about formats, you can avoid most common pitfalls.

Related Tools & Resources