CLDR-17892 ISO 8601 calendar

[macchiati]

CLDR-17892

Most of the time was in writing something that would show the differences clearly. See the results on:

https://docs.google.com/spreadsheets/d/1fIwEYN8AxoJruBuHuMCoer5WIkEBgFD8i1M2quacJiw/edit

Changes from TC review: now retain the G and 'h...a'.

• ISO order doesn't allow for DOW, so I put that after the day, thus before the time.

• The test now makes a few sanity checks, like order of variables

• Had to modify some other files (PathHeader.*, TestDisplayAndInputProcessor.java)

• There were a number of failures due to the wrong space, eg around –. (We should check to make sure that DAIP runs on root too!)

• This PR completes the ticket.

ALLOW_MANY_COMMITS=true

[AEApple]

Interesting it looks like a lot of the differences in the date ranges may be in spacing. Do you want me to propose edits or wait for tomorrow since I wasn't sure how your are generating this list.

[macchiati]

I put in a column for comments, you can add either a recommended change there or a comment.

[macchiati]

I am generating the spreadsheet contents from the root file. That file has the new calendar iso8601, which aliases the gregorian for names of stuff (months, weekdays, etc), but otherwise uses the explicit patterns that were based on root's version of gregorian.

[AEApple]

I am generating the spreadsheet contents from the root file. That file has the new calendar iso8601, which aliases the gregorian for names of stuff (months, weekdays, etc), but otherwise uses the explicit patterns that were based on root's version of gregorian.

ah okay! We could use en-CA as a reasonable proxy, for the most part en-CA is intentionally following ISO with a few exceptions.

[pedberg-icu]

Skeletons with h are only allowed to map to patterns with h or K per the spec, see inline comments.

[macchiati]

The tests might not succeed yet, but I'd appreciate review of the output (now with a column for en_CA).

https://docs.google.com/spreadsheets/d/1fIwEYN8AxoJruBuHuMCoer5WIkEBgFD8i1M2quacJiw/edit

outdated

[AEApple]

I added a few questions, I wasn't sure the answers though.

[macchiati]

Interesting it looks like a lot of the differences in the date ranges may be in spacing. Do you want me to propose edits or wait for tomorrow since I wasn't sure how your are generating this list.

I fixed a batch of cases where the space character was caught by tests (normal vs narrow-nobreak).

[AEApple]

I'm happy to approve since it seems like we just need to make a judgement call for any of the date patterns which are not covered in the ISO spec. Thank you for answering all of my questions.

[macchiati]

ah okay! We could use en-CA as a reasonable proxy, for the most part en-CA is intentionally following ISO with a few exceptions.

I have en-CA in the spreadsheet for comparison. They match pretty well for the pure numeric stuff.

[AEApple]

Okay, naive question, are any other locales inheriting from root, and if so will this mess up their dates? It does look (at least from the surveytool that 'en' inherits a bunch of values from root.

[macchiati]

What will happen is that the formats

Okay, naive question, are any other locales inheriting from root, and if so will this mess up their dates? It does look (at least from the surveytool that 'en' inherits a bunch of values from root.

Not naive at all. I had added the following to the release page:

• Added iso8601 patterns to root. These will use localized months, days of the week, day periods, and timezones. In this first version, the separators are not localized, and will use "-" within numeric dates, ":" within times, and " " or ", " between major elements. Full localization will await the next submission phase for CLDR.

[pedberg-icu]

The standard patters should use HH per ISO format (this would also make them match the corresponding dateTimeSkeleton...)

[macchiati]

Fixed in d954cf9 (and spreadsheet).

[pedberg-icu]

This looks good to me now, thanks!

[AEApple]

I figured out why the AM times confused me for the standard time format examples. I am used to 24 hr times always being zero padded, so when the morning time examples were not zero-padded I automatically read them as 12hr time even though they weren't.

[macchiati]

All merged