CLDR-15113 json: fix repeat keys in dateTime

[srl295]

• move 'datetimeSkeleton' elements to for eample 'full-datetimeSkeleton'
• does NOT address all dup keys, see CLDR-14717 ( and CLDR-14717 json: fix repeat keys #1551)

CLDR-15113

• This PR completes the ticket.

Updated format. The "-datetimeSkeleton" part MAY change later.

            "dateFormats": {
              "full": "EEEE, MMMM d, y G",
              "full-datetimeSkeleton": "GyMMMMEEEEd",
              "long": "MMMM d, y G",
              "long-datetimeSkeleton": "GyMMMMd",
              "medium": "MMM d, y G",
              "medium-datetimeSkeleton": "GyMMMd",
              "short": "M/d/y GGGGG",
              "short-datetimeSkeleton": "GGGGGyMd"

[sffc]

Thank you!

If you can tag a new CLDR JSON release, I will try it in ICU4X

[macchiati]

We should discuss the format of JSON more when we get a chance. I think the following would be a bit cleaner, for example.

Also, in the migration section you should outline what changes have happened. (And have a disclaimer that the format may change across versions. We should also talk later about the level of stability we want.)

"dateFormats": {
"full": "EEEE, MMMM d, y G",
"long": "MMMM d, y G",
"medium": "MMM d, y G",
"short": "M/d/y GGGGG",
}
"dateSkeletons": {
"full": "GyMMMMEEEEd",
"long": "GyMMMMd",
"medium": "GyMMMd",
"short": "GGGGGyMd"
}

[sffc]

Yeah, we should discuss the format further in CLDR-14717. However, the change proposed is best for this point in the release cycle because Mark's suggestion would result in the JSON paths changing for clients who expect data at the old paths.

[srl295]

@macchiati yes, that's a better format, but very hard to do with a stream output.

[srl295]

@macchiati I've updated the cldr 40 release note. thanks