EPOCH Machine Time Interpreter
I. PURPOSE
Epoch resolves machine time for the humans who work with it. It converts any Unix timestamp, ISO 8601 string, or timezone offset to a human-readable date and time — and any human date back to its machine value. It identifies formats before converting them, explains why two systems show different times for the same moment, and surfaces the mechanism behind DST gaps, precision misreads, 32-bit overflow, and epoch boundaries. Machine time is how systems talk to each other. Epoch translates that conversation.
ii. examples
Shows how machine time questions are resolved — the format, the human-readable value, and follow-up paths.
details
1718620800
a: 2024-06-17 at 16:00:00 UTC.
what is the Unix timestamp for December 25 2024 at midnight UTC?
a: 1735084800.
1700000000000
a: 2023-11-14 at 22:13:20 UTC.
2024-03-10T02:30:00-05:00
a: 2024-03-10 at 07:30:00 UTC.
my database shows 2024-06-17 08:00:00 but my API returns 1718611200 — do these match?
a: yes — if the database time is stored and displayed as UTC.
2024-11-03T01:30:00 — why does this timestamp exist twice?
a: no timezone is specified, and in DST-observing zones 01:30 on this date occurs twice.
2026-06-17T00:00:00+05:30
a: 2026-06-16 at 18:30:00 UTC.
2038-01-19T03:14:07Z
a: 2038-01-19 at 03:14:07 UTC — the Year 2038 boundary.
0
a: 1970-01-01 at 00:00:00 UTC — epoch zero.
iii. query intent
details
conversion — machine to human
- what date is unix timestamp 1700000000
- convert epoch time 1735171200 to a readable date
- what does this ISO 8601 timestamp mean in plain English
- what time is this UTC timestamp in my local time
conversion — human to machine
- what is the unix timestamp for January 1 2026
- convert March 15 2025 3pm EST to epoch time
- what is today's date as a unix timestamp
- get the epoch value for a specific date and timezone
format identification
- what format is this timestamp in
- is this an ISO 8601 timestamp or a unix timestamp
- what does this JWT exp field actually represent
- what timestamp format does this HTTP date header use
milliseconds vs seconds vs microseconds
- is this timestamp in seconds or milliseconds
- why is my timestamp showing a date in the year 57000
- how many digits is a millisecond unix timestamp
- why does converting this timestamp give the wrong year
timezone and offset
- what does a UTC offset of +02:00 mean
- what's the difference between UTC and GMT
- why do two systems show different times for the same timestamp
- convert this timestamp to Eastern time
DST effects
- why does this local time not exist during a DST spring-forward
- why does this local time happen twice during a DST fallback
- does daylight saving time affect a unix timestamp
- what happened to my timestamp during the clock change
system mismatch diagnosis
- why does my database show a different time than my API
- why does this Postgres timestamp not match what I expected
- why is my server time different from my local machine time
- why does this log timestamp not match another log for the same event
date arithmetic
- how many days between these two timestamps
- what is the timestamp 30 days from now
- calculate the duration between two unix timestamps
- does a leap year affect this date calculation
database-specific formats
- what's the difference between Postgres timestamp and timestamptz
- what's the difference between MySQL DATETIME and TIMESTAMP
- why does this SQLite date column store text instead of a number
- why does the same stored value display differently in two queries
developer and API context
- what epoch value should I use for this API call
- why is my JWT expiring at the wrong time
- why does my cron job run at the wrong hour
- what does this log timestamp mean relative to this other event
edge cases and concepts
- why was January 1 1970 chosen as epoch zero
- what is the year 2038 problem
- can a unix timestamp be negative
- what's the difference between monotonic time and wall clock time
iv. usage
Applies when a machine time value needs to be converted, identified, diagnosed, or explained — and the answer depends on format, precision, timezone, system context, or DST state.
details
unreadable timestamp
a number or string in a log, API response, database export, error message, or data file that needs to become a human-readable date and time before anything else can happen.
human to machine conversion
a specific date and time that needs to become an epoch value for use in an API call, query parameter, cron expression, JWT field, or system input.
system mismatch
two systems — database and API, server and client, log and log — showing different times for the same moment, where the cause needs to be identified before a fix can be made.
format unknown
a timestamp string that does not look like a standard format and needs to be identified — what system produced it, what standard it follows, and how to read it — before it can be converted.
precision mismatch
a value that may be seconds, milliseconds, or microseconds and is producing a wrong result because the precision was assumed rather than confirmed.
DST boundary
a timestamp that does not exist in a given timezone, exists twice, or shifted unexpectedly during a clock change — and needs to be resolved to a specific UTC instant.
developer context
a JWT expiring at the wrong time, a cron job running at the wrong hour, a scheduled event firing early or late, or a log event that needs to be placed in sequence relative to another.
concept question
someone who has never encountered a Unix timestamp before and needs to understand what the number is, why systems use it, where it comes from, and what epoch zero means.
v. structure
Output is returned as a machine time resolution. Fields appear according to the input. Conversion questions return the human-readable value and UTC equivalent. Mismatch and diagnosis questions return a system note and cause. All outputs include follow-up paths.
details
input
restates the value or question as received.
format
identifies the timestamp format, standard, or type — Unix epoch seconds, milliseconds, ISO 8601, fixed offset, named timezone, or other — before returning the resolved value.
human-readable value
returns the date, time, and timezone in plain language. Leads the response for all conversion questions.
timezone
identifies the offset or named timezone, explains what it means, and notes when timezone is absent or ambiguous.
UTC equivalent
returns the value normalized to UTC so it can be compared across systems.
unix timestamp
returns the epoch value in seconds when the input is a human date or named moment. Appears on human-to-machine conversions.
calculation
returns the result of date arithmetic — duration, difference, or computed future or past value — in the most useful unit.
system note
explains a precision issue, DST effect, format ambiguity, epoch reference difference, or system behavior that affects the value or its interpretation.
why this matters
explains the underlying mechanism — why a timestamp exists twice, why 32-bit overflow happens at a specific second, why milliseconds and seconds produce radically different results — when the mechanism is the point.
next options
offers numbered follow-up paths for timezone conversion, precision confirmation, duration calculation, mismatch diagnosis, or concept explanation tied to the current subject.
vi. handles
Any machine time value or question where the answer depends on format, precision, timezone, system context, or DST state — text input only.
details
Unix epoch values
seconds, milliseconds, and microseconds since 1970-01-01 00:00:00 UTC, including edge cases such as epoch zero, negative values for dates before 1970, and the Year 2038 boundary.
ISO 8601 strings
date-only, datetime, datetime with UTC offset, datetime with Zulu Z suffix, week dates, ordinal dates, and duration notation.
other timestamp formats
RFC 2822, HTTP date headers, SQL datetime and timestamp column types, MongoDB ISODate, JWT iat and exp fields, log timestamps, and file system timestamps.
timezone and offset questions
named timezones, fixed UTC offsets, half-hour and quarter-hour offsets, UTC vs GMT distinction, and conversion between any two timezones or offsets.
DST questions
timestamps that do not exist in a given timezone, timestamps that occur twice during a fallback, clock change effects on stored values, and DST observance by region.
system mismatch questions
disagreements between database and API, server and client, or two logs — where the cause is timezone configuration, session settings, column type behavior, ORM handling, or precision mismatch.
date arithmetic
duration between two timestamps, future or past timestamp from a known value, leap year and leap second effects, and DST-aware duration calculation.
developer and API context
epoch values for API calls, JWT expiry timing, cron job scheduling, log event sequencing, and database timestamp storage and retrieval behavior.
concept and explanation questions
what epoch time is, why 1970 was chosen, what the Year 2038 problem means, what monotonic time is, and why machine time is stored as a number rather than a human-readable string.
vii. limits
Excluded territory and functions this engine does not perform.
details
-
no real-time clock data:
does not return the current time. Resolves timestamps and values provided by the user — does not access live system clocks, NTP servers, or real-time feeds. -
no image or file reading:
text input only. Does not read timestamps from screenshots, log files, PDFs, or uploaded documents. Paste or describe the value. -
not a scheduling or calendar tool:
does not build schedules, set reminders, manage calendar events, or calculate business-day logic beyond what timestamp arithmetic covers. -
not a code generator:
explains timestamp behavior in developer and API contexts but does not write code. For code that handles timestamps use Parse. -
no NTP or clock synchronization guidance:
does not cover network time protocol configuration, clock drift diagnosis, or server time synchronization setup. -
no guaranteed DST rules for all regions:
DST observance, start dates, and end dates vary by region and change over time. Returns best available information but cannot guarantee accuracy for all jurisdictions in all years. -
ambiguous input may require clarification:
when a value could be seconds, milliseconds, or an unrecognized format, and context does not resolve it, clarification is requested rather than a guess returned.
viii. insights
Recurring patterns observed in how machine time values behave across systems, formats, and contexts.
A Unix timestamp is not a format — it is a count. The number of seconds, milliseconds, or microseconds elapsed since 1970-01-01 00:00:00 UTC. Every other representation is a conversion of that count into something human-readable.
The most common timestamp error is precision mismatch. A 13-digit value treated as seconds places an event 53,000 years in the future. A 10-digit value treated as milliseconds places it in 1970. The digit count is the fastest diagnostic.
UTC is not a timezone. It is a time standard — the reference point all offsets are measured from. GMT is a timezone that happens to share the same current offset. They are not interchangeable in systems that observe DST.
A timestamp without a timezone offset is not a unique moment in time. It is a wall clock reading that can map to any number of UTC instants depending on where it was recorded. During DST transitions it may map to two.
DST does not affect Unix timestamps. Because epoch time counts from a fixed UTC reference, the same moment in time always has the same epoch value regardless of local clock changes. DST only affects how that value is displayed in local time.
The most common source of database-to-API timestamp mismatch is not a bug — it is a configuration difference. The database is storing or displaying time in a local session timezone while the API is returning UTC epoch. Same moment, different representation.
ISO 8601 was designed to eliminate date ambiguity across languages and regions. The string 03/04/05 means three different dates depending on locale. The string 2005-03-04T00:00:00Z means exactly one moment everywhere.
The Year 2038 problem is not hypothetical. Systems storing Unix time as a signed 32-bit integer will overflow at 2147483647 seconds — 2038-01-19 03:14:07 UTC. 64-bit systems extend the range to the year 292 billion. The risk is in legacy embedded systems, not modern servers.
Fixed UTC offsets and named timezones are not equivalent. A fixed offset like -05:00 is a static distance from UTC. A named timezone like America/New_York is a set of rules that changes the offset seasonally. The same offset can belong to different timezones at different times of year.
Epoch zero is 1970-01-01 00:00:00 UTC — not because the date is significant, but because it was a round number close to when Unix was being developed. The choice was arbitrary. The consistency it enables is not.
Half-hour and quarter-hour timezone offsets exist because political and geographic boundaries do not align with 15-degree longitude lines. India runs at UTC+05:30, Nepal at UTC+05:45, Iran at UTC+03:30. These offsets are correct and valid.
JWT expiry bugs are almost always timezone bugs. The exp field is a Unix timestamp in seconds. If the issuing system and the validating system disagree on the current time by even a few seconds — due to clock drift, timezone misconfiguration, or DST handling — tokens expire early or never expire at all.
Storing timestamps as UTC and converting to local time only at display is the standard practice for a reason. Local time stored in a database becomes ambiguous the moment the server timezone changes, the application moves regions, or a DST transition occurs.
ix. notes
Resolves machine time values through conversion, format identification, timezone interpretation, and system mismatch diagnosis. Returns the human-readable equivalent, the UTC reference, and the mechanism behind any discrepancy.
details
- difference from a timestamp converter: Returns not just the converted value but the format identification, precision diagnosis, timezone explanation, DST state, and system context that determine whether the value is being read correctly.
- processing model: Combines the input value, its format, the system or context it comes from, and the question type to route through conversion, identification, arithmetic, mismatch diagnosis, or concept explanation.
- input format: Accepts plain text — paste a raw timestamp, describe a time value, or ask a machine time question directly. Examples: "1718620800," "2024-03-10T02:30:00-05:00," "my database and API show different times," "what is epoch zero," "what timestamp is 90 days from now."
- continuation: Can continue from an initial conversion into timezone conversion, precision confirmation, duration calculation, mismatch diagnosis, DST disambiguation, or concept explanation tied to the current subject.
- intended users: Designed for developers, sysadmins, data analysts, QA testers, and anyone working with logs, APIs, databases, exports, or scheduled systems where machine time values need to be read, compared, or diagnosed.
- builder: Designed and maintained by jordan r. hale
x. access
Every tool is fully usable for free — full depth, no account, right now. When you need more, options below.
details
- single tool: unlimited, lifetime, no subscription, one-time purchase.
- domain pack: includes all sibling tools in this domain, current and future. Renews yearly.
- full library: unlimited use across the entire site, current and future. Renews yearly.
- device use: each key works on up to 5 of your devices.
- private page: your unlocked tool, on its own clean page — same tool, no cap, ready whenever you need it.
- app-style use: save that page to your home screen. Opens like an app, no browser tabs.
- updates: any improvements to a tool you've unlocked are included automatically.
xi. privacy
How this engine handles user data and input.
details
- privacy: questions are processed and returned without storage or retention.
- use: no accounts or user profiles; no ongoing tracking.
- usage: daily question counts are stored only on your device, not on our servers.
- interaction: no inbox, follow-up, or outreach.
- payment: checkout (if purchasing access) is handled by Gumroad; this site does not receive card details.
- content: avoid entering sensitive personal or confidential information.
- responses: missing context is labeled; the system does not invent details.