Date/Time Converter
A comprehensive date and time parser that handles Unix timestamps, ISO 8601 dates, RFC 2822 format, US/EU date styles, long dates, and relative expressions. Converts between formats, shows relative time, and provides current timestamp reference.
Specifications
Common Use Cases
- Debug API responses containing timestamps or dates
- Convert log file timestamps to readable dates
- Parse dates from different regional formats
- Calculate time differences between events
- Generate timestamps for API requests
- Verify token expiration times (JWT exp claim)
- Convert between date formats for international teams
Features
- Auto-detect format: Unix timestamps, ISO 8601, RFC 2822, US/EU dates, and more
- Parse Unix timestamps in seconds, milliseconds, microseconds, or nanoseconds
- Handle ISO 8601 dates with or without time (2024-01-25T12:00:00Z)
- Parse US format (01/25/2024), EU format (25.01.2024), and long dates (January 25, 2024)
- Recognize relative expressions: now, today, yesterday, tomorrow
- Show relative time ("2 hours ago", "in 3 days")
- Past/Future/Today status badges
- Display day of week, week number, quarter, and day of year
- Calendar metrics grid (week of year, quarter, day of year)
- Additional info section (timezone, days in month, leap year)
- Convert to multiple output formats with copy buttons
- Unix microsecond and nanosecond output
- Current time reference card with refresh button
Examples
Tips
- JavaScript Date.now() returns milliseconds; most Unix tools use seconds.
- ISO 8601 format (2024-01-25T12:00:00Z) is the most portable and unambiguous format.
- Use UTC timestamps for storage; convert to local time only for display.
- When a date is ambiguous (e.g., 01/02/2024), the tool uses context clues to determine format.
- The "Year 2038 problem" affects 32-bit systems using signed integers for Unix seconds.
Understanding Date/Time
Unix timestamps represent a specific moment in time as the number of seconds elapsed since the Unix epoch: January 1, 1970, at 00:00:00 UTC. This simple integer representation is the universal time format in computing, used by databases, APIs, file systems, log files, and operating system interfaces. The format is unambiguous — unlike human-readable dates, a Unix timestamp always refers to exactly one moment in time regardless of timezone.
Two precision levels are common. Second-precision timestamps (10 digits, like 1738800000) are the traditional Unix format used by most Unix APIs, databases, and the C time() function. Millisecond-precision timestamps (13 digits, like 1738800000000) are used by JavaScript (Date.now()), Java (System.currentTimeMillis()), and many web APIs. This tool auto-detects the precision and handles both correctly.
ISO 8601 is the standard human-readable date-time format: 2025-02-05T12:00:00Z. The T separates date and time, and Z indicates UTC (Zulu time). Timezone offsets use +HH:MM or -HH:MM notation. ISO 8601 is required by JSON Schema, widely used in REST APIs, and recommended for any date-time string interchange. RFC 2822 format (used in email headers) is another common text representation.
Timezone handling is the most common source of date-time bugs. Developers frequently confuse UTC timestamps with local times, apply timezone conversions incorrectly, or store local times without timezone information. Best practice is to always store and transmit times in UTC, converting to local time only for display.
Systems storing Unix timestamps as 32-bit signed integers will overflow on January 19, 2038, at 03:14:07 UTC, wrapping to a negative number that represents December 1901. This is analogous to Y2K but affects computing infrastructure more broadly. The fix is to use 64-bit integers, which extends the range to billions of years. Most modern systems already use 64-bit time, but embedded systems and legacy code may still be vulnerable.
When choosing between storing dates as timestamps or formatted strings, consider the use case. Timestamps (integers) are ideal for computation-heavy scenarios like sorting, calculating durations, and comparing dates — they are compact, unambiguous, and timezone-neutral. ISO 8601 strings are preferable when human readability matters, when timezone context must be preserved, or when the database has native datetime types. PostgreSQL's timestamptz, for example, stores UTC internally and converts for display.
Dates that appear to be off by one day are almost always caused by timezone confusion. A UTC timestamp for February 5 at 23:00 UTC is already February 6 in UTC+2 timezones. In JavaScript, Date() uses local time for date-only strings but UTC for datetime strings with timezone designators. Being explicit about timezones and consistently using UTC for storage and transmission prevents these subtle bugs.