Have syntax for MessageFormat with date/time skeletons


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".


Markus Scherer
January 23, 2019, 12:57 AM

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.

Markus Scherer
September 20, 2018, 5:01 AM

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.

Mihai Nita
September 18, 2018, 11:40 PM

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.


June 30, 2018, 11:56 PM
Trac Comment 15 by —2016-12-07T04:33:46.699Z

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.)

June 30, 2018, 11:56 PM
Trac Comment 14 by —2016-11-28T22:47:25.532Z

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.



Mihai Nita


Mark Davis




Time Needed


Fix versions