Date/Time Converter

What are Date Formats?

A date format defines how a date and/or time value is represented as text. The same moment in time — say, the fifteenth of March, 2024 at half past two in the afternoon in London — can be written in dozens of ways depending on the format, locale, and timezone:

• 2024-03-15T14:30:00Z (ISO 8601)
• 1710513000 (Unix timestamp)
• Fri, 15 Mar 2024 14:30:00 +0000 (RFC 2822)
• 03/15/2024 2:30 PM (US format)
• 15/03/2024 14:30 (European format)
• 2024年3月15日 14時30分 (Japanese)

Date format conversion transforms timestamps between these representations. This is critical for data interchange between systems, APIs, databases, and user interfaces that each expect different formats.

ISO 8601: The Universal Standard

ISO 8601 is the international standard for date and time representation. It uses a strict, unambiguous format that eliminates the confusion between US and European date ordering:

YYYY-MM-DDThh:mm:ss±hh:mm
2024-03-15T14:30:00+01:00

Key properties of ISO 8601:

• Year first: Eliminates DD/MM vs MM/DD ambiguity
• T separator: Clearly divides date from time
• Timezone offset: Explicitly states the UTC offset
• Z suffix: Shorthand for UTC (zero offset)
• Lexicographic sorting: ISO 8601 strings sort correctly as plain text

ISO 8601 is the default format for JSON APIs, JavaScript’s Date.toISOString(), PostgreSQL, and most modern data interchange standards.

Unix Timestamps

A Unix timestamp (also called epoch time or POSIX time) represents a moment as the number of seconds elapsed since January 1, 1970 00:00:00 UTC — the Unix epoch.

1710513000 = 2024-03-15T14:30:00Z

Unix timestamps are compact, unambiguous, timezone-neutral (always UTC), and trivially comparable (just integer comparison). They are the standard internal representation of time in most programming languages and databases.

Variant	Unit	Range	Overflow
Unix (32-bit)	Seconds	1970 - 2038	Jan 19, 2038
Unix (64-bit)	Seconds	1970 - 292 billion years	Never (practically)
Milliseconds	ms	1970 - far future	JavaScript standard
Microseconds	us	1970 - far future	PostgreSQL, Python

JavaScript uses milliseconds since epoch (Date.now() returns milliseconds). Many APIs and databases use seconds. Always check which unit your system expects.

Format Reference

Format	Example	Used By
ISO 8601	2024-03-15T14:30:00Z	APIs, JSON, databases
Unix (seconds)	1710513000	System internals, logging
Unix (milliseconds)	1710513000000	JavaScript, Java
RFC 2822	Fri, 15 Mar 2024 14:30:00 +0000	Email headers, HTTP
Human-readable	March 15, 2024 2:30 PM EST	UI display, reports
SQL	2024-03-15 14:30:00	Databases (no T, no Z)

Time Zones and UTC

Time zones are the single greatest source of date/time bugs. There are over 400 timezone identifiers in the IANA timezone database, and they change regularly — countries adopt, modify, or abolish daylight saving time, shift their UTC offset, or split into new zones.

Key pitfalls:

• DST transitions: Clocks “spring forward” (losing an hour) and “fall back” (gaining an hour). A timestamp like “2024-03-10 02:30 America/New_York” does not exist — clocks jumped from 2:00 to 3:00.
• Timezone abbreviations are ambiguous: “CST” is Central Standard Time (UTC-6), China Standard Time (UTC+8), and Cuba Standard Time (UTC-5). Always use IANA timezone identifiers (America/Chicago, Asia/Shanghai).
• Non-integer offsets: India is UTC+5:30, Nepal is UTC+5:45, and Chatham Islands (New Zealand) is UTC+12:45.

Common Pitfalls

1. Storing local time without timezone. A bare 2024-03-15 14:30:00 is meaningless without knowing which timezone it refers to. Always store UTC or include the offset.

2. Assuming 24 hours in a day. DST transitions create 23-hour and 25-hour days. Time arithmetic that adds 86400 seconds to advance one day will be wrong twice a year.

3. Using timezone abbreviations. “PST” and “PDT” are different offsets. Use America/Los_Angeles and let the library determine the correct offset for any given date.

4. Ignoring leap seconds. UTC occasionally adds a leap second (23:59:60). Most systems ignore leap seconds, but GPS time, NTP, and some financial systems account for them.

Common Use Cases

• API integration: Converting timestamps between the format your API returns (ISO 8601, Unix) and the format your database or frontend expects
• Log correlation: Converting timestamps from different services (each possibly in different formats and timezones) to a common format for unified log analysis
• Scheduling across timezones: Converting meeting times, deployment windows, or maintenance schedules between team members’ local times
• Data migration: Transforming date columns when moving data between databases with different timestamp formats (Unix epoch in Redis vs ISO 8601 in PostgreSQL)
• Debugging time-related bugs: Converting Unix timestamps from error logs into human-readable dates to understand when events occurred