UUID Timestamp

The UUID timestamp tool extracts embedded time from version 1 UUIDs and builds v1 UUIDs from chosen datetimes. Distributed systems use UUID v1 for roughly time-ordered identifiers — MAC address and clock sequence fill the remaining bits. Paste a canonical 8-4-4-4-12 string to read when it was generated; pick an instant to synthesize a valid v1 for replication tests and sort-key experiments.

What UUID version 1 encodes

RFC 4122 version 1 packs a 60-bit timestamp in 100-nanosecond units since 1582-10-15 UTC (Gregorian reform anchor), plus version and variant nibbles, clock sequence, and node id. The timestamp is not Unix epoch — do not feed UUID hex into the Unix timestamp converter without parsing structure first.

Version 4 UUIDs are random — this page cannot extract time from them. Version 7 (time-ordered random) uses Unix ms in newer specs — treat separately from v1. For bare epoch integers use Unix timestamp; for LDAP attrs use LDAP timestamp.

Extracting time from an existing UUID

Paste the full hyphenated string. The decoder reads timestamp bits, applies epoch offset, and displays UTC civil time. Precision is finer than one second internally; display may round for readability. Clock sequence and node id are shown for debugging duplicate-key collisions when clocks step backward.

Privacy note: v1 node ids often embed MAC addresses — treat extracted hardware hints as sensitive in public postmortems. Prefer v4 or v7 for public-facing tokens when specification allows.

Generating UUID v1 for tests

Pick a datetime and optional clock seq/node overrides for deterministic fixtures. Integration tests asserting chronological sort on primary keys need stable v1 inputs across CI runners — document whether you freeze node to avoid MAC leakage in logs.

Compare generated UUID time with ISO strings from the ISO 8601 converter when APIs return both fields and QA must prove consistency.

Worked examples

Example A: database row id 6fa459ea-ee8a-3ca4-894e-db77e1603552 — extract time to correlate row creation with deploy window without trusting application created_at column alone.

Example B: message bus uses v1 for ordering — decode first and last message UUIDs in a partition to estimate spread when wall clocks drifted during 2026 daylight saving cutover.

Example C: security review finds v1 tokens in browser localStorage — extracted node ids trigger rotation to v4 recommendation in threat model doc.

Sorting and indexing implications

v1 ids are roughly time-sortable in string compare when generated on same node with monotonic clock — not guaranteed globally. Database b-tree indexes on random v4 avoid hot spots; v1 trades insert locality for predictability. Choose consciously when designing 2026 sharding schemes.

Extracted timestamps help forensic sort when created_at column was nullable and backfilled incorrectly.

Clock rollback and duplicates

When system clock steps backward, RFC clock sequence increments to reduce collision risk — duplicate timestamps possible but unlikely in same millisecond window. If load tests generate thousands of v1 per second, watch for uniqueness violations in unique indexes.

Virtual machine snapshots restoring old clock times exacerbate rollback — hypervisor time sync matters more than UUID math.

Interop with other time formats

Windows COM GUIDs and .NET Guid.NewGuid() default to v4 — not decodable here. Java UUID.randomUUID() same. Some legacy COM servers emitted v1 — know your stack. MongoDB ObjectId embeds seconds since epoch differently — not UUID v1.

Batch log correlation: extract v1 times, convert companion Unix fields on the batch timestamp page, merge timelines in UTC.

Distributed databases and sort keys

Cassandra and similar stores use TimeUUID types embedding v1 clock — extract time here when comparing with application created_at epoch column during schema migration debates. Document whether new services should adopt UUID v7 instead for 2026 greenfield APIs.

Extracted v1 timestamps help forensic ordering when application clock and database default disagree on insert order during incident review.

Privacy-preserving deployments

Regulations increasingly discourage MAC-based node ids in v1 — OS vendors randomize node bits while keeping v1 structure. Extraction still yields time portion; treat node field as opaque when writing public docs about token structure.

Pen testers demonstrating token predictability should cite v1 time extract in reports with remediation to v4 — include decoded exp alongside for complete session risk picture.

Microservice trace correlation

OpenTelemetry spans carrying trace ids as UUID v1 allow extract-time ordering when log aggregation loses sub-second sort — decode first span in burst during 2026 latency incident review. Service mesh mTLS cert rotation logs embed v1 in serial experiments on legacy nodes — extract time to map cert generation cluster.

Document whether new 2026 services mint v4 exclusively in architecture decision record — link this page for legacy v1 decode path only.

Event sourcing and CQRS journals

Event stores using UUID v1 as event id allow approximate timeline reconstruction when wall-clock skew suspected — extract time from disputed events during 2026 audit replay. Snapshot metadata referencing v1 generation instant helps compare with aggregate version clock in distributed system postmortems.

Greenfield 2026 services should document UUID version choice in README — v7 for sortable random time, v4 for opaque ids, v1 decode documented here for legacy readers only.

Compliance archives exporting message ids as v1 UUID should redact node portion in public FOIA response while retaining extracted time for chronological index — legal and engineering agree redaction scope before 2026 disclosure batch.

Data retention policy citing UUID v1 generation time must distinguish extractable clock from user content deletion schedule — legal hold may block purge even when extracted timestamp suggests aged record eligible for 2026 cleanup job.

Architecture review checklist item: list UUID version per service boundary before 2026 security audit intake.

Legacy message bus migration runbook: decode sample v1 ids before cutover weekend to validate ordering assumptions against new v7 emitter.

Related tools

Epoch seconds: Unix timestamp. Windows AD: LDAP timestamp. All formats: converters hub.