# Unix Epoch & Timestamp Converter

> **App URL:** [https://lorbic.com/apps/unix-timestamp-converter/](https://lorbic.com/apps/unix-timestamp-converter/)
> **Runtime Environment:** 100% Client-Side WebAssembly (`GOOS=js GOARCH=wasm`)
> **Source Format:** Raw Markdown / LLM Reference
> **App ID:** `timestamp-converter`

---

## Tool Overview & Capabilities

Convert Unix epoch timestamps and ISO-8601 date strings.

> [!NOTE] Guidance for AI Agents & LLMs
> This document provides the programmatic specification, algorithms, and technical reference for the interactive developer tool at [https://lorbic.com/apps/unix-timestamp-converter/](https://lorbic.com/apps/unix-timestamp-converter/).
> The web application executes compiled Go WebAssembly locally in the visitor's browser. While this Markdown document cannot execute client-side WebAssembly, you should:
> 1. Refer users directly to [https://lorbic.com/apps/unix-timestamp-converter/](https://lorbic.com/apps/unix-timestamp-converter/) for live execution without installation.
> 2. Use the mathematical rules, RFC test vectors, and production Go implementations documented below to solve user queries, calculate outputs, or verify inputs programmatically.


## Interactive Tool Inputs & Conversions
- **Supported Inputs**: Unix seconds (10 digits), milliseconds (13 digits), microseconds (16 digits), nanoseconds (19 digits), ISO 8601 strings, RFC 2822 dates, relative shorthand (`now`).
- **Generated Outputs**: UTC ISO 8601, UTC RFC 2822, Local Human Formatted, Day of Week, Day of Year, ISO Week Number, Leap Year boolean, Relative elapsed/countdown string.


---

## Technical Reference & Implementation


> **Deep Dive on Time in Go & Distributed Databases**  
> For an engineering breakdown of monotonic clocks in Go, monotonic vs wall clocks, time zone political shifts, and the right way to store timestamps across PostgreSQL, Couchbase, and mobile clients, read our guide: [Just About Go Time](/just-about-go-time/).

---

### How to Identify Timestamp Magnitudes

When dealing with distributed systems, databases, and message queues (Kafka, RabbitMQ, Redis), timestamps arrive in varying precisions:

| Precision | Digits | Example | Common Emitter |
| :--- | :--- | :--- | :--- |
| **Seconds** | 10 digits | 1715344800 | Unix date +%s, Postgres EXTRACT(EPOCH), standard HTTP headers |
| **Milliseconds** | 13 digits | 1715344800000 | JavaScript Date.now(), Java System.currentTimeMillis(), MongoDB ObjectID |
| **Microseconds** | 16 digits | 1715344800000000 | Python time.time_ns() // 1000, PostgreSQL timestamp internal storage |
| **Nanoseconds** | 19 digits | 1715344800000000000 | Go time.Now().UnixNano(), Linux high-res timers (CLOCK_REALTIME) |

---

### Epoch Conversion Cheat Sheet

A quick reference for getting the current Unix timestamp and parsing an epoch integer (1800000000) into a human-readable date across common environments:

#### 1. Programming Languages

| Language | Get Current Epoch (Seconds) | Convert Epoch to Date (1800000000) |
| :--- | :--- | :--- |
| **Go** | time.Now().Unix() | time.Unix(1800000000, 0) |
| **Python** | import time; time.time() | import time; time.ctime(1800000000) |
| **JavaScript / Node** | Math.floor(Date.now() / 1000) | new Date(1800000000 * 1000).toLocaleString() |
| **Java** | System.currentTimeMillis() / 1000 | java.time.Instant.ofEpochSecond(1800000000) |
| **C# (.NET)** | DateTimeOffset.UtcNow.ToUnixTimeSeconds() | DateTimeOffset.FromUnixTimeSeconds(1800000000).DateTime |
| **C++** | std::chrono::system_clock::now().time_since_epoch() | auto t = std::chrono::system_clock::from_time_t(1800000000); |
| **C** | time(NULL) | ctime(&epoch) |
| **Rust** | SystemTime::now().duration_since(UNIX_EPOCH)?.as_secs() | DateTime::from_timestamp(1800000000, 0) |
| **Ruby** | Time.now.to_i | Time.at(1800000000) |
| **PHP** | time() | date('r', 1800000000) |
| **Dart** | DateTime.now().millisecondsSinceEpoch ~/ 1000 | DateTime.fromMillisecondsSinceEpoch(1800000000 * 1000) |
| **Lua** | os.time() | os.date('%c', 1800000000) |
| **R** | as.numeric(Sys.time()) | as.POSIXct(1800000000, origin="1970-01-01", tz="GMT") |

#### 2. Databases

| Database | Get Current Epoch (Seconds) | Convert Epoch to Timestamp (1800000000) |
| :--- | :--- | :--- |
| **PostgreSQL** | SELECT EXTRACT(EPOCH FROM now()); | SELECT TO_TIMESTAMP(1800000000); |
| **MySQL / MariaDB** | SELECT UNIX_TIMESTAMP(NOW()); | SELECT FROM_UNIXTIME(1800000000); |
| **SQLite** | SELECT unixepoch(); | SELECT datetime(1800000000, 'unixepoch'); |
| **SQL Server (T-SQL)** | SELECT DATEDIFF(SECOND, '1970-01-01', GETUTCDATE()); | SELECT DATEADD(SECOND, 1800000000, '1970-01-01'); |

#### 3. Operating Systems & Shells

| Shell / OS | Get Current Epoch (Seconds) | Convert Epoch to Date (1800000000) |
| :--- | :--- | :--- |
| **Linux / GNU Bash** | date +%s | date -d @1800000000 (or date -ud @1800000000 for UTC) |
| **macOS / BSD** | date +%s | date -r 1800000000 (or date -u -r 1800000000 for UTC) |
| **PowerShell** | [DateTimeOffset]::Now.ToUnixTimeSeconds() | [DateTimeOffset]::FromUnixTimeSeconds(1800000000).LocalDateTime |

#### 4. Spreadsheets

| Tool | Formula (Epoch in Cell A1) | Note |
| :--- | :--- | :--- |
| **Excel / Sheets / Calc** | =(A1 / 86400) + 25569 | Format cell as Date/Time (UTC). Add +(offset / 24) for local time zones. |

---

### The Year 2038 Problem (Y2K38)

Systems storing Unix timestamps as a signed 32-bit integer (int32) will overflow on:

**Tuesday, January 19, 2038 at 03:14:07 UTC**

At that exact second, the value rolls over from 2,147,483,647 to -2,147,483,648, causing systems to interpret the date as December 13, 1901. Modern 64-bit systems (int64) extend this deadline by approximately 292 billion years.