Heh. Do we know what calendar we want to use?
In LibreOffice, we still have the odd Julian calendar for display for pre-Gregorian times. There are lots of issues arising from that.
Then, we chose the “there is no year 0” idea. But e.g. SQLite uses proleptic Gregorian with year zero (preferred by astronomers, by the way). No idea what PostgreSQL does in that regard, though. Python decided that there was no life before CE. Should we re-consider that, when choosing the algorithm?
And most of all: which specific problem are you trying to solve? OK, you decide to use e.g. Julian Day-based count in LibreOffice at runtime. (By the way, “7980 years-long” is utterly insufficient for us, where we use years through 32767 - you may say that it’s not required, but changing that would be a regression for many). OK; but how does that change what is stored in database? in documents? How these different bases interact? Or do we break all existing documents, and ignore interoperability with other implementations?
By the way, “having fast and efficient formulas” to convert e.g. to Jalali calendar (which, by definition, is not algorithmic) is unlikely.
There are lots of interesting questions around chronology. But there is no definite, single correct answer for any of them. I see all the side-stories here as just wishful thinking. The small change I made improved one small detail. A large change will most likely not improve anything.