Reading timestamps from logs and databases
Correlating events across systems means converting each to a common zone. An epoch value in a log line is unreadable until converted.
Utilities🔒 Browser (client-side)API available📴 Works offlinebeginner
Unix Timestamp
Converts Unix timestamps to human-readable dates and back.
Data stays in your browser
Ready to runInstant execution
Result
—What does this tool do?
Converts Unix timestamps to human-readable dates and back.
Why would I use it?
- An API returned a timestamp and you want the date.
- You need the current Unix time for a script.
- You are debugging a timezone bug.
Real-life example
Input
1754985600
Output
2026-08-12 00:00:00 UTC (and your local time)
Seconds and milliseconds are both supported.
Input → Process → Output → Next
- Input
- Enter a timestamp or a date.
- Process
- The browser converts with timezone handling.
- Output
- The corresponding date/time in UTC and local.
- Next action
- Confirm which unit (seconds vs ms) your API uses.
Common mistakes
- Confusing seconds with milliseconds (10-digit vs 13-digit).
- Forgetting that timestamps are UTC.
- Expecting the same local display everywhere.
What the result means
The timestamp represents an instant in time, shown in UTC and local.
Privacy & security
Your input is processed entirely in your browser and never sent to a YAS server.
API
Endpoint
POST https://yas.sh/api/v1/tools/unix-timestamp
Request Header
Content-Type: application/json
cURL
curl -X POST "https://yas.sh/api/v1/tools/unix-timestamp" \
-H "Content-Type: application/json" \
-d '{"input":"1754500000"}'JavaScript
const res = await fetch("https://yas.sh/api/v1/tools/unix-timestamp", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
"input": "1754500000"
}),
});
const data = await res.json();Python
import requests
r = requests.post("https://yas.sh/api/v1/tools/unix-timestamp", json={"input":"1754500000"})
data = r.json()| Field | Type | Required | Description |
|---|---|---|---|
| input | string | Yes | e.g. 1754500000, 1754500000000, or an ISO date (blank = now) |
Success response
{ "slug": "unix-timestamp", "result": { "unix": 1754500000, "iso": "2025-08-06T18:26:40.000Z", "utc": "..." } }Convert a unix timestamp (s/ms) ↔ ISO/UTC date.
Error responses
400 VALIDATION_ERROR— invalid input or unsupported option.413 PAYLOAD_TOO_LARGE— input exceeds the 64 KB limit.429 RATE_LIMIT_EXCEEDED— rate limit exceeded (60 req/min).
Limits
- Maximum input: 64 KB per request.
- Rate limit: 60 requests/min per IP address.
- Authenticated accounts benefit from higher tier quotas.
Unix Timestamp: technical reference, use cases and FAQ
How Unix Timestamp works
A Unix timestamp counts seconds since 1970-01-01T00:00:00Z, excluding leap seconds — the count is defined against UTC in a way that repeats a second rather than incrementing through it, which is why the value maps cleanly to a civil date but is not a true count of elapsed physical seconds. Conversion applies the Gregorian calendar rules to that offset, then optionally shifts into a local time zone.
The two recurring bugs are units and zones. JavaScript's Date.now() returns milliseconds while most backends, databases and APIs use seconds, so a value passed unconverted is either 1,000 times too large or lands in 1970. And a timestamp has no time zone at all: it identifies an instant, and the date a user sees depends entirely on which zone it is rendered in — which is why a value can legitimately show two different calendar dates to two users.
When to use it: real-world scenarios
Debugging token expiry
JWT exp and iat are epoch seconds. Converting them shows whether a token is genuinely expired or whether the verifier compared against milliseconds.
Scheduling and comparing events
Storing instants as epoch integers makes comparison and arithmetic trivial and avoids every ambiguity of parsing date strings.
Checking daylight-saving behaviour
Converting a timestamp into a zone that observes DST shows how the same instant renders on either side of a transition.
Pro tips
- Store instants in UTC, always. Convert to local time only at the moment of display; storing local times creates ambiguity twice a year that cannot be resolved afterwards.
- Check whether an API means seconds or milliseconds before doing arithmetic. A ten-digit value is seconds, a thirteen-digit value is milliseconds.
- For future events tied to human schedules — a recurring meeting — store the local time and the IANA zone identifier, not a fixed instant. Governments change offsets.
- Use 64-bit integers for timestamps. 32-bit signed values overflow on 19 January 2038, and embedded systems still ship with them.
Limitations and edge cases
What this tool deliberately does not do, and where it will disagree with other implementations.
- Leap seconds are not represented; the epoch count is deliberately smoothed over them.
- Zone conversions depend on the IANA time zone database, which changes when governments alter their rules.
- Dates before 1970 are negative and are handled inconsistently by some systems.
- A timestamp alone cannot express a floating local time such as 'every day at 09:00 wherever the user is'.
Frequently asked questions
- Is a Unix timestamp in seconds or milliseconds?
- The standard is seconds; JavaScript's Date.now() is a common exception returning milliseconds. Count the digits — ten is seconds through the 2030s, thirteen is milliseconds.
- Does a Unix timestamp include a time zone?
- No. It identifies an instant in UTC. The calendar date a user sees depends on the zone used for display, which is why the same value can show as two different dates.
- What is the year 2038 problem?
- A signed 32-bit timestamp overflows on 19 January 2038, wrapping to 1901. Modern systems use 64-bit values, but embedded devices and legacy database columns remain exposed.
- Why is my date one day off?
- A time zone offset, usually UTC being rendered as local time or the reverse. Near midnight, a few hours of offset moves the calendar date.
Related tools