Unix Epoch Time Converter - Timestamp to Date Tool
Convert Unix timestamps and Windows FILETIME (PE headers, malware analysis) to readable dates. Supports batch conversion, hex/decimal FILETIME formats, forensic timeline analysis.
Want to learn more?
Learn about Unix timestamps, epoch time, and why this format is the backbone of time handling in modern software.
Read the guideDebugging Timestamp Issues?
Our developers handle timezone complexity, timestamp formatting, and time-series data.
What Is Unix Timestamp Conversion
A Unix timestamp (also called Epoch time or POSIX time) represents a point in time as the number of seconds elapsed since January 1, 1970, 00:00:00 UTC — known as the Unix Epoch. This integer representation is the standard time format used by operating systems, databases, APIs, log files, and programming languages because it is timezone-independent, unambiguous, and easy to perform arithmetic on.
Unix timestamps appear everywhere in technical systems: API responses, database records, JWT tokens, file metadata, log entries, and system calls. Converting between human-readable dates and Unix timestamps is a daily task for developers, system administrators, and security analysts.
Timestamp Formats
| Format | Example | Precision | Range |
|---|---|---|---|
| Unix seconds | 1706400000 | Seconds | 1970-01-01 to 2038-01-19 (32-bit) |
| Unix milliseconds | 1706400000000 | Milliseconds | JavaScript Date.now(), Java System.currentTimeMillis() |
| Unix microseconds | 1706400000000000 | Microseconds | Python time.time_ns(), database precision |
| Unix nanoseconds | 1706400000000000000 | Nanoseconds | Go time.Now().UnixNano() |
| ISO 8601 | 2024-01-28T00:00:00Z | Varies | Human-readable standard |
| RFC 2822 | Sun, 28 Jan 2024 00:00:00 +0000 | Seconds | Email headers |
The Year 2038 Problem
32-bit signed integers can store Unix timestamps up to 2,147,483,647 — which corresponds to January 19, 2038, 03:14:07 UTC. After this moment, 32-bit systems will overflow, potentially causing failures similar to Y2K. Most modern systems use 64-bit timestamps, which extend to approximately 292 billion years.
Common Use Cases
- API development: Convert between Unix timestamps in API responses and human-readable dates for display and debugging
- Log analysis: Translate Unix timestamps in server logs, security events, and application logs to understand when events occurred
- JWT token inspection: Decode exp (expiration), iat (issued at), and nbf (not before) claims in JSON Web Tokens, which use Unix timestamps
- Database queries: Convert between database timestamp types and Unix epochs when writing queries or analyzing data
- Forensic timeline construction: Convert file system timestamps, log entries, and authentication records to a common format for timeline analysis
Best Practices
- Always store and transmit in UTC — Convert to local time only for display. Storing timestamps in local time creates ambiguity and breaks during daylight saving transitions.
- Use ISO 8601 for human-facing formats — YYYY-MM-DDTHH:MM:SSZ is unambiguous, sortable, and internationally recognized. Never use MM/DD/YYYY (is 01/02/2024 January 2nd or February 1st?).
- Check milliseconds vs seconds — A timestamp of 1706400000000 is milliseconds (year 2024), not seconds (year 56054). JavaScript and Java use milliseconds; most Unix tools use seconds.
- Use 64-bit integers — If your system uses 32-bit timestamps, plan migration before 2038. Modern languages and databases support 64-bit timestamps by default.
- Account for clock skew — In distributed systems, clocks on different servers may diverge. Use NTP synchronization and design systems to tolerate small clock differences.
References & Citations
- Wikipedia. (2024). Unix time. Retrieved from https://en.wikipedia.org/wiki/Unix_time (accessed January 2025)
- International Organization for Standardization. (2019). ISO 8601 Date and Time Format. Retrieved from https://www.iso.org/iso-8601-date-and-time-format.html (accessed January 2025)
Note: These citations are provided for informational and educational purposes. Always verify information with the original sources and consult with qualified professionals for specific advice related to your situation.
Key Security Terms
Understand the essential concepts behind this tool
Frequently Asked Questions
Common questions about the Unix Epoch Time Converter - Timestamp to Date Tool
Unix timestamp (epoch time) is seconds elapsed since January 1, 1970, 00:00:00 UTC (the "Unix epoch"). Example: 1609459200 = January 1, 2021, 00:00:00 UTC. Used because: timezone-independent (always UTC), easy arithmetic (1735689600 - 1609459200 = seconds between dates), compact storage (32-bit integer vs date string), universal standard across programming languages, sortable (higher number = later time). Negative values represent dates before 1970. 2038 problem: 32-bit timestamps overflow on January 19, 2038 (2,147,483,647 seconds) - solved with 64-bit integers. This tool converts between Unix time and readable formats instantly.
Unix timestamps use seconds by default (10 digits: 1609459200). JavaScript uses milliseconds (13 digits: 1609459200000) - multiply by 1000 to convert. Identify by length: 10 digits = seconds, 13 digits = milliseconds, 16 digits = microseconds (rare). Conversion: seconds × 1000 = milliseconds, milliseconds ÷ 1000 = seconds. Why milliseconds: higher precision for timing events, JavaScript Date() expects milliseconds, performance measurement needs sub-second accuracy. Use seconds for: dates, events, logs. Use milliseconds for: timestamps in code, performance metrics, precise event timing. This tool detects format automatically and converts between both.
Unix timestamps are always UTC - timezone-agnostic. Display conversion adds timezone offset. Example: 1609459200 displays as "Jan 1, 2021 00:00 UTC" or "Dec 31, 2020 19:00 EST" (UTC-5). Storage best practice: always store UTC timestamps, convert to local timezone only for display. Avoid storing local time (ambiguous during DST transitions, moving users between zones). Common mistakes: comparing timestamps from different zones, forgetting DST shifts, using local time in databases. Solutions: use UTC everywhere in backend, convert to user timezone in frontend only, ISO 8601 format for APIs (2021-01-01T00:00:00Z). This tool shows timestamps in multiple timezones simultaneously.
JavaScript: new Date(1609459200 * 1000) for seconds, Date.now() gets current milliseconds. Python: datetime.fromtimestamp(1609459200), time.time() for current. PHP: date("Y-m-d H:i:s", 1609459200), time() for current. MySQL: FROM_UNIXTIME(1609459200), UNIX_TIMESTAMP() for current. PostgreSQL: to_timestamp(1609459200), extract(epoch from now()). Java: new Date(1609459200L * 1000), System.currentTimeMillis(). Go: time.Unix(1609459200, 0), time.Now().Unix(). Remember: JavaScript/Java use milliseconds, most others use seconds. This tool generates code snippets for common languages.
32-bit signed integers max at 2,147,483,647 (January 19, 2038, 03:14:07 UTC) then overflow to negative (wraps to December 13, 1901). Affects: legacy 32-bit systems, embedded devices, old databases, C/C++ time_t on 32-bit platforms. Solutions: use 64-bit integers (supports year 292 billion+), update system libraries, upgrade to 64-bit OS, use unsigned 32-bit (extends to 2106). Modern systems: 64-bit by default (Python, JavaScript, Java long, PostgreSQL bigint). Check your system: if storing timestamps as 32-bit int, migrate to 64-bit now. This tool uses 64-bit timestamps supporting dates far beyond 2038.
Subtract timestamps to get seconds difference: 1735689600 - 1609459200 = 126230400 seconds. Convert to units: ÷ 60 = minutes, ÷ 3600 = hours, ÷ 86400 = days, ÷ 31536000 ≈ years. Example: 126230400 ÷ 86400 = 1,461 days = 4 years. For elapsed time: current_timestamp - event_timestamp. For future events: event_timestamp - current_timestamp. Add duration: timestamp + (days × 86400). Subtract duration: timestamp - (hours × 3600). Advantages: no timezone confusion, no DST issues, simple arithmetic. Disadvantages: doesn't account for months (varying lengths) or leap seconds. This tool calculates differences and shows results in multiple time units.
Mixing seconds and milliseconds - most common error. Use 10 digits (seconds) vs 13 (milliseconds). Timezone confusion - storing local time instead of UTC. Solution: always UTC. String comparison - "1609459200" > "999999999" lexically wrong. Use numbers. 32-bit overflow - timestamps after 2038. Use 64-bit. Leap seconds - Unix time ignores them (occasionally 61 seconds in minute). Not an issue for most apps. Float vs integer - precision loss in milliseconds. Use integers. Negative timestamps valid (pre-1970 dates). Forgetting to multiply/divide by 1000 when converting to JavaScript. This tool validates input and prevents common conversion errors.
Convert to Date object then format per locale. US: MM/DD/YYYY (01/15/2025), Europe: DD/MM/YYYY (15/01/2025), ISO 8601: YYYY-MM-DD (2025-01-15 - unambiguous). Time: 12-hour (3:30 PM) vs 24-hour (15:30). JavaScript: new Intl.DateTimeFormat("en-US").format(date). Libraries: date-fns, Moment.js (deprecated), Luxon, Day.js. Include timezone in display: "Jan 15, 2025 3:30 PM EST". Best practice: let user set preference or detect from browser locale (navigator.language). API responses: always use ISO 8601 with timezone: 2025-01-15T15:30:00Z. This tool formats timestamps in common regional formats with timezone support.
Windows FILETIME is a 64-bit value representing 100-nanosecond intervals since January 1, 1601 00:00:00 UTC (Windows epoch). Used throughout Windows: PE file headers (TimeDateStamp), registry timestamps, NTFS metadata, event logs. Malware analysts need FILETIME because: PE compilation timestamps reveal when malware was built, registry modifications show persistence mechanisms, file system timestamps indicate infection timeline, Windows event correlation requires timestamp synchronization. Example: FILETIME 133774656000000000 (decimal) = 0x1DA3A7E8E3F0000 (hex) = 2024-12-04. Common in: exe/dll headers, Windows Registry forensics, memory dumps, NTFS analysis. This tool converts FILETIME ↔ Unix ↔ human-readable for rapid malware timeline reconstruction.
Conversion formula: Unix = (FILETIME / 10000000) - 11644473600, where 10000000 converts 100-ns intervals to seconds, 11644473600 is seconds between 1601 and 1970. Reverse: FILETIME = (Unix + 11644473600) × 10000000. Example: PE header TimeDateStamp 0x65703B80 (hex) = 1701892992 (Unix seconds) = Dec 6, 2023. FILETIME formats: decimal (18 digits: 133774656000000000), hexadecimal (0x prefix: 0x1DA3A7E8E3F0000). This tool supports both: select input format (Unix/FILETIME-decimal/FILETIME-hex), paste value, get all conversions instantly. Auto-detect: values > 100000000000000 assumed FILETIME, 0x prefix = hex. Batch mode: paste multiple timestamps for forensic timeline analysis.
Common FILETIME locations: PE headers - IMAGE_FILE_HEADER.TimeDateStamp (Unix 32-bit, not FILETIME but needs conversion), debug directory timestamps. Registry - HKLM\SOFTWARE modification times, persistence keys (Run, RunOnce). NTFS - (creation, modification, MFT change, access times), timestamps. Event logs - Windows Event Log .evtx entries. Memory dumps - process creation times, thread start times. Prefetch files - execution timestamps. Tools extract these as hex/decimal - this converter translates to readable dates. Malware timeline: compile time → dropper execution → persistence installation → C2 communication. Analyst workflow: extract timestamps from tools (PEStudio, Registry Explorer, MFTECmd), paste into batch converter, build attack timeline.