Timestamp & System Time Decoder

Epoch is an AI tool for decoding timestamps and working out what machine-time values mean.

Paste or describe a timestamp, encoded time value or suspicious date, and Epoch identifies how the value is encoded, what moment it represents, and why a date or duration is reading incorrectly.

A correct conversion is not always a correct answer. Epoch uses the source of the value, the unit, the reference point, the clock that produced it and the surrounding system context to separate a bad timestamp from a bad interpretation or a bad clock.

timestamp format identifier

• Determines the likely unit, epoch and representation of an unknown value from source context, magnitude and format clues before converting.

epoch converter

• Converts Unix seconds, milliseconds, microseconds and nanoseconds into a readable date, and back again.

Windows FILETIME and LDAP timestamp converter

• Converts Active Directory and LDAP values counted in 100-nanosecond intervals from 1601.

.NET ticks converter

• Converts DateTime ticks counted in 100-nanosecond intervals from year 1.

Excel and spreadsheet date converter

• Converts day serials and fractional days into a readable date, and identifies which date system a workbook is using.

Chrome, WebKit and Cocoa timestamp converter

• Converts browser and Apple application timestamps counted from 1601 and 2001.

Mac HFS+, NTP and GPS time converter

• Converts filesystem, network-time and satellite-time values counted from 1904, 1900 and 1980, including the GPS leap-second offset.

time-bearing identifier decoder

• Reads creation-time information carried inside MongoDB ObjectId, UUIDv1, UUIDv7, ULID and Snowflake identifiers.

written timestamp parser

• Interprets ISO 8601, RFC 3339, UTC markers, offsets, locale-formatted dates, older protocol formats and packed or binary representations.

wrong date diagnosis

• Separates wrong units, wrong epochs, zero values, damaged imports, bad source clocks and storage limits that each produce plausible-looking but incorrect dates.

spreadsheet and import mangling diagnosis

• Identifies where a date column was altered by locale inference, type guessing or conversion on import, including values changed in the stored data rather than the display.

timezone and daylight saving diagnosis

• Explains naive and aware datetimes, offsets against named zones, repeated or missing local hours, and schedules that shift, skip or run twice.

clock disagreement diagnosis

• Separates clock offset, drift and skew, and explains why two machines, logs or distributed traces disagree about one event.

wall clock and monotonic clock checker

• Identifies where a corrected wall clock was used to measure duration and states when a monotonic clock should have been used.

precision and accuracy checker

• Distinguishes precision from accuracy, and states what resolution the clock actually measured rather than what the format can hold.

truncation and rounding finder

• Identifies the rounding, truncation or numeric limit that removed low-order detail in storage or transit.

database and interchange behaviour reader

• Explains database column behaviour, interchange formats and file metadata, and what changes when a time value crosses between systems.

range and overflow checker

• Identifies fixed-width formats that cannot represent a requested date, including Y2K-style representation failures and 2038-style counter overflow.

file and photo timestamp reader

• Explains what created, modified, accessed and capture timestamps each record, why they disagree, and what an inconsistency between them indicates.

timestamp evidence assessment

• Separates ordinary metadata from stronger evidence.
• States what timestamp consistency, independent records and cryptographic timestamping can establish.

Paste the timestamp, date value, identifier or written time exactly as it appears, and say where the value came from.

Include the operating system, application, database, file type, API, log source or programming language, along with the expected date range, the time zone, and whether the question concerns a moment, a duration or the order of events.

Where a number supports several valid interpretations, Epoch names the plausible formats and states which piece of source context would separate them.

identify an unknown value

questions people ask:

"What format is 133988736000000000 from Active Directory?" · "Is 1735689600 seconds or milliseconds?" · "What is an 18-digit date value?" · "FILETIME or .NET ticks — both are 18 digits."

convert a timestamp

questions people ask:

"Convert a Unix timestamp to a readable date." · "What date is a FILETIME of 132537600000000000?" · "Convert an Excel serial of 45874.5." · "What moment do .NET ticks of 638400000000000000 represent?"

convert a browser, Apple or network timestamp

questions people ask:

"What is this Chrome history timestamp?" · "Convert a Cocoa Core Data date." · "What is a Mac HFS+ timestamp of 3837244800?" · "Why is GPS time ahead of UTC?"

explain a wrong date

questions people ask:

"Why does a record show 1 January 1970?" · "Why did a value convert to the year 58505?" · "Why are dates in an export centuries off?" · "Why is a birthday one day out?"

fix imports and storage

questions people ask:

"Why did half a CSV date column change on import?" · "Why is Excel turning product codes into dates?" · "Why did MySQL change a stored timestamp?" · "Why did the microseconds disappear from a Postgres column?"

find where precision was lost

questions people ask:

"Why did the microseconds become .000?" · "Does TIMESTAMP(0) round or truncate?" · "Why do two records now have identical timestamps?" · "Is the extra precision real or just storage?"

solve time zone and daylight saving problems

questions people ask:

"Why does 01:30 exist twice in October?" · "Why did a nightly cron job run twice?" · "Why does a scheduled report arrive an hour early half the year?" · "What is the difference between an offset and a named zone?"

diagnose clock disagreement

questions people ask:

"Why do two servers show times 42 seconds apart for one event?" · "Why are application logs out of order?" · "Why did a child span start before its parent?" · "Why does a TLS certificate read as not yet valid?"

measure duration and order events

questions people ask:

"Why did an elapsed time come out negative?" · "Wall time or monotonic time for a benchmark?" · "Which of two API calls actually happened first?" · "Can timestamps order events across machines?"

read identifiers and file metadata

questions people ask:

"How do I get the date out of a MongoDB ObjectId?" · "Can a timestamp be extracted from UUIDv7?" · "Why is the date on a phone photo wrong?" · "What is the difference between date taken and date created?"

work with range limits

questions people ask:

"Why won't a date in 2040 save?" · "What is the year 2038 problem?" · "What actually went wrong in Y2K?" · "What is GPS week rollover?"

assess timestamp evidence

questions people ask:

"Can file dates be trusted?" · "Can a modified date be faked?" · "The creation date is later than the modified date — what does that mean?" · "How do I prove a document existed on a certain date?"

the format identification

• the likely timestamp format or representation;
• the unit being counted;
• the epoch or reference point;
• the source clues supporting the identification;
• alternative interpretations where the value is ambiguous;

the conversion

• the decoded readable date and time;
• the calculation or conversion logic;
• the relevant time-zone or offset interpretation;
• the timestamp embedded inside a supported identifier;

the diagnosis

• whether the problem is a conversion error, source-clock error, storage problem or display problem;
• whether daylight-saving rules create an ambiguous or nonexistent local time;
• why two clocks or systems disagree;
• where rounding, truncation or numeric representation changed the value;

precision and limits

• the precision available in the format and the precision the system likely preserved;
• whether a wall clock or monotonic clock is appropriate;
• the range or overflow limit of the relevant format;

ordering and evidence

• whether timestamp order is reliable enough to establish event sequence;
• what file, photo or database timestamp metadata establishes;
• what additional evidence or context would resolve an uncertain reading;

where to go next

• follow-up directions for conversion, diagnosis or deeper system-time analysis.

why a raw timestamp does not identify itself

Digit count only narrows it so far — FILETIME and .NET ticks are both eighteen digits for current dates, and the ticks value is always the larger because it starts counting sixteen centuries earlier. Source context identifies the format more reliably than the number.

why the same instant carries many different values

Unix seconds, milliseconds, Windows FILETIME, .NET ticks and spreadsheet serials all describe the same moment using different units and different zero points. The choice of zero point is arbitrary and historical: 1601 for a complete Gregorian cycle, 1904 for early Apple hardware, 1970 for Unix, 1980 for GPS, 2001 for Cocoa.

why a plausible conversion can still be wrong

Most incorrect assumptions produce a valid-looking date, so plausibility is checked against the source, the expected period and the surrounding records rather than against whether a converter returned an answer.

why a timestamp can be correct while the event time is wrong

A system can store and convert a value perfectly and still record the wrong moment, because the clock that produced the value was already wrong. A computer clock drifts by ten to twenty seconds a day uncorrected, and even a synchronised one is only aligned between sync intervals.

why precision is not accuracy

A format capable of nanoseconds says nothing about whether the clock measured nanoseconds, and extra digits often reflect storage capacity rather than real temporal resolution.

how precision disappears without warning

Truncation is usually silent by design. The SQL standard permits either rounding or truncation on store assignment and requires no warning, so a column declared to whole seconds accepts a microsecond value and keeps the seconds. The same happens whenever a value passes through a layer with less resolution than the one before it, which is why sub-millisecond detail rarely survives a round trip through a language whose native date type stops at milliseconds.

why spreadsheets change the data rather than the display

A spreadsheet infers types on import, and once it decides a cell is a date it rewrites the underlying value, not just its appearance. That is why the damage survives reformatting the column afterwards, and why the safe move is declaring the column as text before the data arrives rather than fixing it after.

why wall time and elapsed time answer different questions

Wall clocks answer when and can be corrected; monotonic clocks answer how long and are built not to move backwards. Confusing the two produces impossible durations — a negative elapsed time is usually a wall clock that was corrected mid-measurement.

why time-zone problems affect labels rather than instants

A stored epoch count passes through daylight-saving transitions unchanged, while bare local readings become duplicated, missing or ambiguous. An offset is not a zone: an offset is a number at one moment, a zone is a set of rules about when that number changes.

why clocks disagree, and what it breaks

Skew is the difference between two clocks now; drift is the rate at which they separate. A hundred and fifty milliseconds of skew is normal for network time synchronisation and is still enough to put records out of order, make a "last five minutes" query miss rows, and let last-write-wins pick the wrong write. In tracing it produces child spans starting before their parents.

why timestamps are weak evidence alone

Ordinary file and system timestamps are writable metadata, and tools exist specifically to backdate them. Confidence comes from consistency across records that are not all writable by the same process — a creation date later than a modification date is the classic tell — or from a timestamp tied to an external integrity record.

machine time raises many kinds of question

Machine time raises many kinds of question:

• unknown numeric values: which timestamp format, unit and epoch a number uses;
• timestamp conversion: turning machine counters into readable dates and times;
• Unix time: seconds, milliseconds, microseconds and nanoseconds since the Unix epoch;
• non-Unix epochs: Windows FILETIME, .NET ticks, NTP, GPS, Chrome, Cocoa, Mac HFS+ and other reference points;
• spreadsheet dates: day serials, fractional days and date systems that do not count seconds;
• written timestamps: ISO 8601, RFC 3339, UTC, offsets and older date formats;
• wrong dates: values resolving to 1970, 1900, absurd future dates or consistently shifted dates;
• imports and exports: date columns changed by locale inference, type guessing or conversion between systems;
• precision: seconds through nanoseconds, rounding, truncation and misleading extra digits;
• database storage: timestamp column types, range limits, conversions and silently lost precision;
• time zones: UTC, local time, offsets, named zones, aware and naive datetime values;
• daylight saving: missing hours, repeated hours, jobs running twice or schedules drifting by an hour;
• clock problems: drift, skew, synchronisation failures and machines whose clocks are simply wrong;
• duration measurement: negative elapsed time and wall-clock against monotonic-clock mistakes;
• distributed events: logs or traces whose timestamps produce impossible ordering;
• event order: when clock comparison suffices and when causal or sequence ordering is needed;
• time-bearing identifiers: extracting dates from ObjectId, UUIDv1, UUIDv7, ULID, Snowflake and similar schemes;
• calendar arithmetic: durations, months, ages, anniversaries, leap years and leap seconds;
• certificate validity: certificates reading expired or not yet valid because the local clock is wrong;
• file and photo dates: created, modified, capture and metadata timestamps and why those fields disagree;
• timestamp evidence: what a timestamp supports, how timestamps can be altered and how stronger proof is created;
• range limits: Y2K, 2038, GPS week rollover and other formats that eventually run out of room.