Also, I'll note that these 2 use cases, for a calendar month enum, don't necessarily involve the use of a numeric index (which I agree could be a weakness in approach): get the next/previous month, get the number of the months in a year.

Yes, exactly

Z28154 is already a throw function.

I've investigated too, and the main problem is that currently Julian calendar dates are not fetched

The Dagbani reading function (Z23990) already support the mdy Dagbani format (for example, the input "06-09-2025" is correctly interpreted as 9 June 2025)

Can you explain what the use case is?

The ISO 8601 formats (like yyyy-mm-dd or yyyymmdd) are instead guaranteed to be interpreted as such in all the languages by the reader function Z20808.

Excuse me for the problems that I have caused, but most of those examples were created by me. It was when I was still new at Wikifunction, and I didn't understand well how types are actually used (now I'm planning to convert all those functions to use strings instead of monolingual texts). At the time, I had understood that there was supposed to be the the language code that I was lefting blank, but I didn't manage to understand how to insert it (I expected that I had to click in the chip to activate an input box inside of it that would let me insert the language code). Since everything still worked well (the functions completely ignored the language field of the monolingual texts, and this is why now I am converting them to use simple strings), I just renounced to try to insert the correct language code.

Could you please add the support for blank fields also for Z20159 (Gregorian Year)?

It also affected me trying to add a Z802 call for this edit: https://www.wikifunctions.org/wiki/Z20442?diff=prev&oldid=191465

Perhaps it's better to use '{{#time:Y-m-d}}', since in this way it uses the ISO 8601 format. The d/n/Y format could be misinterpreted by the reader functions in some languages (for example, the en-us reader interprets 06/8/2025 as '8 June 2025').