AlphaDec is a human-readable, lexically sortable UTC encoding.
It's designed to be timezone-agnostic, reversible, and safe for use in LLMs, filenames, and database keys.
Examples like 2025_M4O2_todo.txt carry timing information (seasonal + positional) but avoid ISO collisions.
It encodes the full UTC year as a symmetrical orbital structure:
26 periods × 10 arcs × 26 bars × 10 beats. Each one tickable in JS, Bash, or Python.
Inspired by the clean abstractions of Snowflake IDs, but readable by humans and AIs.
> LLM & AI-Native: Its structured, tokenizable nature makes it powerful primitive for time-based reasoning, prompt engineering, and log analysis in AI systems.
Being significantly OOD usually does not help in this case, did I miss something here?
The OOD thing ironically helps a bit because sometimes AI can skim over regular timestamps and say two different times are the same etc. LLMs don't actually parse and calculate the timestamps after all. With AlphaDec it's very clear that two timestamps are different
Also I use a little preamble... here is what I send Anthropic's Claude Sonnet when it asks for the current AlphaDec over an MCP tool
// AlphaDec units (approx): Period = UTC yr (different length leap yr vs common yr) / 26 ≈ 14.04 days | Arc ≈ Period / 10 ≈ 33.7 hours | Bar ≈ Arc / 26 ≈ 77.75 minutes | Beat ≈ Bar / 10 ≈ 7.78 minutes. The final part of canonical AlphaDec is milliseconds offset within the beat. Period F, Period M, Period S, and Period Z always contain equinoxes/solstices. Truncating significant digits creates natural time groupings, eg 2025_M2 contains 'every alphadec in this arc'
[
{
"timezone": "UTC",
"iso": "2025-07-25T00:47:09.219Z"
},
{
"timezone": "AlphaDec",
"alphadec": "2025_O6B3_087680",
"readable": "O6:B3"
}
]
Hi folks, my project:
AlphaDec is a human-readable, lexically sortable UTC encoding. It's designed to be timezone-agnostic, reversible, and safe for use in LLMs, filenames, and database keys.
Examples like 2025_M4O2_todo.txt carry timing information (seasonal + positional) but avoid ISO collisions.
It encodes the full UTC year as a symmetrical orbital structure: 26 periods × 10 arcs × 26 bars × 10 beats. Each one tickable in JS, Bash, or Python.
Inspired by the clean abstractions of Snowflake IDs, but readable by humans and AIs.
Live clock: https://firasd.github.io/alphadec/
Interesting images of Claude reverse-engineering it:
1. https://firasd.github.io/alphadec/assets/2025_O3U4_alphadec_...
2. https://firasd.github.io/alphadec/assets/2025_O3U4_alphadec_...
3. https://firasd.github.io/alphadec/assets/2025_O3U4_alphadec_...
4. https://firasd.github.io/alphadec/assets/2025_O3U4_alphadec_...
The project states that:
> LLM & AI-Native: Its structured, tokenizable nature makes it powerful primitive for time-based reasoning, prompt engineering, and log analysis in AI systems.
Being significantly OOD usually does not help in this case, did I miss something here?
The OOD thing ironically helps a bit because sometimes AI can skim over regular timestamps and say two different times are the same etc. LLMs don't actually parse and calculate the timestamps after all. With AlphaDec it's very clear that two timestamps are different
Also I use a little preamble... here is what I send Anthropic's Claude Sonnet when it asks for the current AlphaDec over an MCP tool
// AlphaDec units (approx): Period = UTC yr (different length leap yr vs common yr) / 26 ≈ 14.04 days | Arc ≈ Period / 10 ≈ 33.7 hours | Bar ≈ Arc / 26 ≈ 77.75 minutes | Beat ≈ Bar / 10 ≈ 7.78 minutes. The final part of canonical AlphaDec is milliseconds offset within the beat. Period F, Period M, Period S, and Period Z always contain equinoxes/solstices. Truncating significant digits creates natural time groupings, eg 2025_M2 contains 'every alphadec in this arc' [ { "timezone": "UTC", "iso": "2025-07-25T00:47:09.219Z" }, { "timezone": "AlphaDec", "alphadec": "2025_O6B3_087680", "readable": "O6:B3" } ]
And always, the big asterisk on using UTC instead of TAI: https://cr.yp.to/proto/utctai.html