Epoch Pack Versioning

BinVer

A 32-bit seconds-since-epoch timestamp, split across X.Y.Z. No legibility, no wasted bits, no compromises. Maximum range, maximum precision.

Formula

s = seconds since 2025-01-01 00:00:00 UTC

X = (s >> 24) & 0xFF  // high byte
Y = (s >> 16) & 0xFF  // mid byte
Z = s & 0xFFFF  // low 16 bits

The version triple is simply a 32-bit unsigned integer in big-endian layout: X holds bits 31–24, Y holds bits 23–16, Z holds bits 15–0. Reassemble with s = X×16777216 + Y×65536 + Z, or equivalently s = (X << 24) | (Y << 16) | Z.

X
0 – 255
Bits 31–24
Y
0 – 255
Bits 23–16
Z
0 – 65535
Bits 15–0

Examples

Datetime (UTC)SecondsVersion

As you can see, BinVer versions are completely opaque. 4.117.830 means nothing to a human. That's the point — this scheme prioritizes machine efficiency over human readability.

Converter

—
—

Properties

Monotonic sorting. Because the integer is stored big-endian across X.Y.Z, standard version comparison produces the same order as comparing the raw integer. Later timestamps always produce higher versions.
136-year range. 232 = 4,294,967,296 seconds ≈ 136 years. With epoch 2025, the scheme covers through approximately 2161.
Second resolution. Every second maps to a unique version. No two builds can collide unless they happen within the same second.
Trivial to implement. Three bit shifts. No multiplication, no division, no month tables, no edge cases.

When to use BinVer

BinVer is for systems where humans never look at version numbers directly: embedded firmware, infrastructure services, internal tools, automated pipelines. If your version is only ever compared by machines, there's no reason to waste encoding space on legibility. Use every bit.

If anyone on your team will ever say a version number out loud, use SunVer or MoonVer instead.