Epoch - Machine Time Interpreter
Continue Using Epoch
$49 USD — One-time purchase. Lifetime access.
No subscription.
Includes the Epoch Web Utility and a ChatGPT-compatible version with future updates.
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
Questions about machine time — converting, identifying, diagnosing, and explaining timestamps, formats, offsets, and time values across systems, APIs, databases, logs, and code.
details
conversion — machine to human
Converts any Unix epoch value, ISO 8601 string, or machine timestamp to a human-readable date and time, including timezone, UTC equivalent, and precision.
conversion — human to machine
Returns the Unix epoch value for any described or written date and time, including timezone-aware conversion and millisecond output.
format identification
Identifies what a timestamp format is, how it is structured, and what system or standard it comes from before converting. Covers Unix epoch, ISO 8601, RFC 2822, HTTP date headers, SQL datetime, MongoDB ISODate, JWT iat and exp fields, log timestamps, and file system timestamps.
milliseconds vs seconds vs microseconds
Identifies whether a value is seconds, milliseconds, or microseconds, explains what goes wrong when precision is misread, and converts between precisions.
timezone and offset
Explains what a timezone offset means, converts a moment to a specific named timezone or fixed offset, distinguishes UTC from GMT, and explains why named timezones and fixed offsets behave differently.
DST effects
Explains why a timestamp does not exist in a given timezone, why a local time occurs twice during a DST fallback, what happened to a value during a clock change, and which regions observe DST and when.
system mismatch diagnosis
Identifies why two systems show different times for the same moment — database vs API, server vs client, log vs log. Diagnoses timezone configuration, session settings, ORM behavior, column type differences, and storage vs display mismatches.
date arithmetic
Calculates duration between two timestamps, computes a future or past timestamp from a known value, and flags DST transitions or leap years that affect the calculation.
database-specific formats
Resolves Postgres timestamptz vs timestamp, MySQL DATETIME vs TIMESTAMP, SQLite text dates, and why the same stored value displays differently depending on session timezone or column type.
developer and API context
Resolves what epoch value to use in an API call, why a JWT expires at the wrong time, why a cron job runs at the wrong hour, and what a log timestamp means relative to another event in the same system.
edge cases and concepts
Explains epoch zero and why 1970 was chosen, the Year 2038 boundary and which systems are affected, negative timestamps for dates before 1970, and the difference between monotonic 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
How to unlock full access and what is included.
details
- full access: one-time purchase.
- private page: opens the full web version of the tool without preview limits.
- app-style use: save the private page for direct access.
- gpt version: optional ChatGPT version of the tool.
- updates: improvements included over time.
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.
- 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.