With decades of experience with Roman, Jewish, Arabic calendars, that is not the way. Record calendar events as unix time (e.g. signed 64 bit secs since 1970) and calendar type (and thus how dates are displayed) is selected in the client. You could call it "star date" (since calendars and day length were different on every planet) or "nostradate" and pick a funky origin. Java time uses 64 bit milliseconds since 1970 - that works too.
Discussion
That's an interesting approach...🤔🧐
If that means we can all use our preferred calendar, I like it a lot!🫂😁
We all live by our own calendar while being able to coordinate with any and every other calendar via "UTC Date" (Universal Time, Coordinated).
Rather than Unix time, we might want the benchmark to be the bitcoin Genesis Block?🤔🧐😁
UTC is just another calendar. You want a straight single number, counting some units some an origin. You'll want a stable frame of reference also that is easily quantified - otherwise I'd pick the CMB (Cosmic Microwave Backgroup) FoR (in which the universe is ~5.5 days old). For the foreseeable future, this means Earth FoR. Bitcoin blocks is not a useful time unit for future events either. Seconds are pretty universal on Earth, and well standardized.
What is the Bitcoin genesis block time origin in secs since 1970 or some standard calendar?
Note that modern calendars depend on observations to determine leap seconds - so future date display may be off by a second or two. Lunar calendars generally have leap months - and in the Hebrew calendar, the leap month is applied according to an official New Moon observation in Israel. This can be affected by war or weather, so you can't always predict when the next leap month will be, and future date display may be off by a lunar month. But, this is part of the charm of lunar calendars.