Unix timestamp to date converter

Wetin be Unix timestamp?

Unix timestamp, wey dem still call am Unix time or POSIX time, na di number of seconds wey don pass since 1970-01-01 00:00:00 UTC, wey dem know as di Unix epoch. E be one standard wey dem use well well for computing because e take one single integer to represent wetin time suppose be, so e make storage, comparison, and arithmetic straightforward.

JavaScript work internally with milliseconds, so Date.now() return Unix timestamp multiply by 1000. Plenty API, database, and backend system dem use seconds instead. Dis tool here accept both kind and e go detect seconds or milliseconds automatic base on di size of di number wey you enter.

Unix timestamps wey important

Why 1970?

Dem choose di Unix epoch of January 1, 1970 partly because of convention and partly because of practical matter wey dem face. Unix dem develop am for late 1960s and early 1970s at Bell Labs. Di developers need one recent, round starting date for dia time representation. January 1, 1970 been recent enough to work and no get special technical meaning — e just be one place wey convenient to start from.

Different epoch dates dem exist for other system: di Windows FILETIME epoch na January 1, 1601; GPS time start January 6, 1980; di NTP epoch na January 1, 1900. When you wan convert between system, you must know wetin each system epoch be.

Seconds versus milliseconds

Di original Unix timestamp na for seconds. Most server-side language and system (Unix shell, Python time.time(), PHP time(), most database dem) dem use seconds. JavaScript Date.now() and new Date().getTime() dem return milliseconds. Dis difference na one common thing wey cause problem when JavaScript frontend talk with backend API.

Unix timestamp wey for seconds na currently one 10-digit number (around 1,700,000,000 from 2023). Millisecond timestamp na one 13-digit number. Di calculator detect wetin format you enter base on di number of digit and convert am well well.

Di Year 2038 problem

System wey dem store Unix timestamp as signed 32-bit integer go fit only represent date until 2,147,483,647 seconds after di epoch — wey be 03:14:07 UTC on January 19, 2038. After dat time, one 32-bit signed integer go overflow to one big negative number, wey represent one date for 1901.

Dem sometimes call am "Y2K38" problem or di Unix Millennium Bug. Modern 64-bit system no get dis problem, because one signed 64-bit integer fit represent timestamp for approximately 292 billion year. But embedded system, old database, and older 32-bit software dem still fit get di problem. Plenty industry — including telecommunications, banking, and industrial control system — dem dey do work to fix dis.

How you go get di current Unix timestamp

Real-real use wey dem use am for

API development: REST API dem normally use Unix timestamp for created_at, updated_at, and token expiry field. One timestamp no get timezone problem and e clear clear — not like formatted date string wey depend on locale and formatting.

Token expiry: JWT (JSON Web Token) dem use Unix timestamp for di exp (expiry) and iat (issued at) claim. One token expire when di current timestamp pass di exp value. When you calculate expiry time — "dis token suppose expire for 24 hour" — you go add 86,400 seconds to di current timestamp.

Cache TTL: Cache expiry dem normally set am as Unix timestamp or as number of seconds from now. When you dey debug cache problem, you go need to convert di stored expiry timestamp to date wey human fit read.

Log analysis: Server log dem often get Unix timestamp inside. Converting dem to readable date na di first step when you wan match log entry with real-real event.

Database storage: When you store timestamp as integer instead of formatted string, you avoid timezone conversion problem and e make sorting, range query, and arithmetic simple. One query for "all record from di last 7 day" go become WHERE created_at > (NOW_UNIX - 604800).