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?

And always, the big asterisk on using UTC instead of TAI: https://cr.yp.to/proto/utctai.html

Entered with scepticism but left convinced. Looks very thoughtfully designed, nice!

I admit i do feel a bit uneasy about the rational numbers used in the definition, but i guess it doesn't matter for the purposes of this? And you do seem to have considered it. I still wonder if a less neat but integer-second or -millisecond definition might be useful, as round tripping could then be well defined i think? (If, as another poster hinted, you consider the interaction with leap seconds too)

Hmm

ISO 8601: 2025-06-14T23:37:42.814Z

is far more readable than

alphadec: 202025_L0V3_001827

no?

Anything is human-readable, if you think this is. This is more human-readable than a QR code, I guess, but that isn’t saying much.

> ISO 8601 - Not sort-friendly as a string (unless zero-padded)

The zero padding is in fact part of the format.

> ISO 8601 - Verbose

It's an extra few characters but I can also tell what date it is and what time of day it is by looking at it.

Also you can remove the separators to make it only 4 characters longer.

On the other hand if you really want it to be compact, AlphaDec doesn't do the job. To go from year down to second you need 8 characters, and then 3 more for milliseconds. Base32 would need 5 and then 2 more.

There's probably a good middle ground here but I think AlphaDec sacrifices too much. I'd much rather have something that encodes month, day, and hour into one character each so even if I didn't memorize which is which I can at least truncate by them instead of periods, arcs, and bars.

I think the pure 4-character version has some good appeal, but both truncating it and extending it for better precision lose most of that appeal.

> ISO 8601 - Not great for filenames or embeddings

I guess, but using a different character from colon is a very simple tweak you can make.

  AlphaDec: 2025_L0V3_001827
  
  Instead of:
  
  ISO 8601: 2025-06-14T23:37:42.814Z

This is misleading. The precision is less than 1 min, So it should be:

  AlphaDec: 2025_L0V3_001827
  
  Instead of:
  
  ISO 8601: 2025-06-14T23:37
  
  or

  DateTime: 20250614_2337

This format is a Rube Goldberg machine which adds nothing to the table.

BTW: was this format designed with the help of an LLM? LLMs can easily misunderstand or miss the big picture, while over-optimizing for small details.

  AlphaDec: 2025_L0V3 (or full canonical: 2025_L0V3_000000)
  UTC: June 5th, 2025 at 13:45

  2025_L0V3_000000
  20250605_1345000

  2025_L0V3_000
  20250605T134500Z

  2025_L0V3_000000
  20250605T134500.000Z

  2025_L0V3_000000
  20250605_134500000

  2025_L0V3_000.000
  20250605_134500.000

A decimal digit encodes approximately 3.3 bits. The current Unix timestamp (barely) fits into 32 bits, so it should take approximately 10 decimal digits to represent. The number of seconds since the beginning 0 CE fits into 36 bits, so requires 12 decimal digits at least. The ISO timestamp (YYYY-mm-dd HH:MM:SS) requires 4 + 4 + 6 = 14 decimal digits.

If we wanted to compress the representation while remaining within ASCII and allowing for textual sorting and easy glancing, our best bet is something like base64: Latin upper case + lower case + digits give us 66 characters, a soupçon more than 6 bits per character. We'd need only 6 characters to represent a 36-bit timestamp with 1 second precision, and just 5, for a minute precision. Yay!

Better yet, since timekeeping is base 60 since Sumerian times, we could directly represent minutes and seconds with one digit each, using base60 (with a room to spare for the leap second). Relinquishing 1.5 more bits, we could use only 24 distinct values for hours, allowing for a clear separation of "date" and "time"; time would take 3 characters, like D7a.

If we agree to spend 2 characters (12 bit) for month + day, then the month and the day directly map to one character each. Now allocate 2 characters for the year, and we're set until year 4095, when we could reconsider.

So, we have a timestamp of 2 + 2 + 3 = 7 characters, only one longer than the theoretical minimum, and with quite a room to spare. The result directly maps to the traditional calendar dates, with year, month, day, hour, minute, second being separate digits, and which is readable, sortable, pronounceable, and trimmable. (Now we only need to write it in cuneiform again.)