Time Converter

Convert between Unix timestamps and human-readable dates, perform timezone conversions, and calculate time differences. A comprehensive tool for developers working with dates and times.

Time Converter

Convert between Unix timestamps and human-readable dates with timezone support.

Supports both seconds (10 digits) and milliseconds (13 digits)

Time Conversion Tips & Best Practices

Navigate timezone complexities, understand Unix timestamps, avoid DST pitfalls, and handle international time correctly in your applications.

Seconds vs milliseconds timestamps?
Understanding different Unix timestamp precisions

Unix timestamps come in different precisions:

  • Seconds (10 digits): Traditional Unix, used by most systems
  • Milliseconds (13 digits): JavaScript, Java, modern APIs
  • Microseconds (16 digits): High-precision logging
  • Nanoseconds (19 digits): Scientific applications

Quick check: Count the digits!

  • 1704067200 = seconds (10 digits)
  • 1704067200000 = milliseconds (13 digits)

Mixing them up causes dates 1000x in the future or past!

Unix TimePrecision
Why does my time change by an hour?
Daylight Saving Time (DST) gotchas

DST causes numerous timezone conversion issues:

  • Times can be ambiguous (2 AM happens twice when clocks fall back)
  • Times can be invalid (2 AM doesn't exist when clocks spring forward)
  • Duration calculations break (PT36H ≠ P1DT12H during DST)
  • Future times become uncertain (DST rules can change)

Best practice: Always store times in UTC, convert only for display. UTC has no DST!

DSTTimezone
What's the difference between GMT and UTC?
Understanding time standards and their usage

While often used interchangeably, they're technically different:

  • GMT: Astronomical time based on Earth's rotation
  • UTC: Atomic time, the modern standard
  • UTC is more precise (atomic clocks vs solar observation)
  • For programming, always use UTC

Other timezone tips:

  • Use IANA timezone names (America/New_York, not EST)
  • Avoid 3-letter codes (CST = Central or China?)
  • UTC offset isn't enough (multiple zones per offset)
UTCStandards
How do I handle dates far in the future?
Y2038 problem and long-term date storage

The Y2038 problem affects 32-bit Unix timestamps:

  • 32-bit signed integers overflow on 2038-01-19 03:14:07 UTC
  • Many systems still use 32-bit time representation
  • Embedded systems and IoT devices especially vulnerable

Solutions:

  • Use 64-bit timestamps (good until year 292277026596)
  • Store as ISO 8601 strings for readability
  • Consider domain-specific formats for far dates
  • Test your systems with post-2038 dates now
Y2038Future Dates
What's ISO 8601 and when should I use it?
The international standard for date/time representation

ISO 8601 is the standard format for dates and times:

  • Format: 2025-01-15T14:30:00Z
  • Always unambiguous (YYYY-MM-DD order)
  • Sortable as strings
  • 'Z' suffix means UTC (Zulu time)

With timezone offset:

2025-01-15T14:30:00+09:00

Limitations: Offset doesn't indicate timezone (both Tokyo and Seoul are +09:00). For future events, store timezone name separately.

ISO 8601Format
Why don't my timestamps match?
Common timestamp comparison issues

Timestamp mismatches often come from:

  • Precision mismatch: Comparing seconds to milliseconds
  • Timezone assumptions: Local time vs UTC
  • Leap seconds: Unix time ignores them
  • System clock drift: Servers out of sync

Debugging tips:

  • Log both raw timestamp and formatted time
  • Check system timezone settings
  • Verify NTP synchronization
  • Use consistent precision throughout
DebuggingTimestamps
How to schedule across timezones?
Best practices for international applications

Scheduling for global users requires careful planning:

  • Store all times in UTC internally
  • Store user's timezone preference (IANA format)
  • Convert to local time only for display
  • Show timezone in UI to avoid confusion

For recurring events:

  • Store in user's local timezone (for DST handling)
  • Recalculate UTC time when DST changes
  • Example: "Every Monday 9 AM" should stay 9 AM after DST
SchedulingInternational
What are leap seconds?
Why Unix time isn't perfectly accurate

Leap seconds compensate for Earth's slowing rotation:

  • Added irregularly (27 times since 1972)
  • Unix time ignores them (assumes 86400 seconds/day)
  • Can cause timestamps to repeat or skip
  • UTC includes them, Unix time doesn't

Impact: Usually negligible for applications, but critical for:

  • Financial trading systems
  • Scientific measurements
  • GPS and navigation
  • Distributed system synchronization

Most systems "smear" the leap second over several hours.

Leap SecondsAccuracy