To use a message format with a skeleton you have to use some ugly code.
Would be much easier for callers if we added an option to:
Something like either "skeleton", or "datetime".
I don't like "skeleton" by itself because it is not obviously for a date/time format.
I also don't like one type value to be used for both numbers and date/times (as Mark suggested in ) based on the "style" field; that would be confusing and add complications into the code. (It would also be inconsistent with how MessageFormat has worked so far.)
"datetimeskeleton" would be clear but even longer than "selectordinal".
I think "dtskeleton" is a nice compromise, but Mark calls that a "mongrel"
Consistently short would be "dts" but that's again too obscure.
"datetime" might be ok but sounds a lot like the "date" and "time" we already have, with no obvious distinction of pattern vs. skeleton.
I don't like "dtskeleton". It is not particularly informative (nd dnt lk jst rmvng lttrs t rndm).
I don't think we anticipate having any other kind of skeleton than the date/time skeleton, so just "skeleton" is ok. It's a technical term anyway, that will cause people to look at the the documentation anyway, since they will know it is not just ☠️ .
Frankly, "dts", while obscure at first, it is no more opaque than "date/time skeleton" once someone looks it up the first time (which they'll do, since "skeleton", again, will not mean anything to someone who's unfamiliar with them, so they'll know they have to consult the docs.)
This is pretty old now (2 years), and meantime we have some "precedents" for number formats:
So it is currently possible to use a skeleton for number formats, like this:
It uses the same argType as before and start the pattern with ::
So I propose we do the same for dates / times.
There is no need to use the word "skeleton" in the argType (so no need "dtskeleton"), but we would need a "datetime" option.
I agree that we should just use :: for date/time skeletons as ICU 62 added for number skeletons.
We don't need a "datetime" type if we don't have one already. We can just make it work for both "date" and "time", and the skeleton determines the actual set of fields.
Reassigning to Mihai who implemented date/time skeleton syntax using the "::" prefix.
Shane used the same prefix earlier for number skeletons.
Mihai: Please update the documentation (API docs & User Guide) and then close this ticket.