Support unclear dates for tournaments

[mbergen]

There are several wikis with tournaments that have partial dates (e.g. YYYY-??-??), which are then stored as YYYY-01-01.
Search query: : hastemplate:Infobox_league insource:/edate=<1990-2026>-(<01-12>|\?+)-\?+/

CS and VAL store extradata.enddate_raw, and old versions of TournamentsTicker/TournamensListing did support display of the raw dates.
The standardized versions should allow this as well, and ideally the storage would happen in commons infobox/league.

[hjpalpha]

display of those becomes a nightmare if you use different formats from YYYY-MM-DD (which according to salle is the way to go)

[mbergen]

As in, allow different input formats? Or different output formats?

[hjpalpha]

as in how would we even display those
currently we use
https://github.com/Liquipedia/Lua-Modules/blob/main/lua/wikis/commons/TournamentsListing/CardList.lua#L460-L481

i don't see a way to easily display 20??-??-?? like that ...

[mbergen]

I'd only support unknown days and months, not years. Keeping the current format, we would essentially just omit the unknown part.
So if both start- and enddate are 2024-??-??, we could just display 2024
If they are 2024-10-?? and 2024-11-??, we could display Oct - Nov, 2024

[hjpalpha]

what about e.g. |sdate=2025-12-31 with |edate=202?-??-???
(shouldn't happen often but there exist events which take >1 year... where the edate is unknown for a very very long time)

also: this requires quite a few additional functions (preferably in DateExt) and it will likely impact runtime a bit

[mbergen]

As i said, at the start i would not support unknown years at all, i'd argue that your use case would very rarely be used. Most often it would be fine to assume 2026 for the edate in your example, and perhaps change it when it really reaches 2027.
The usecase this aims to support is mostly about tournaments that have been cancelled, and thus a rough timeframe is known, but no exact dates.

There are are few hundred uses of edate with unknown month or day, and not a single one with a ? in the year field.
In addition, the runtime increase would be very marginally, the matching already happens right now, storing another field in extradata is not relevant runtime-wise either.

[ElectricalBoy]

related: #6476