<i18n dev> RFR: 8247781: Day periods support [v7]

[Naoto Sato]

On Thu, 5 Nov 2020 23:49:25 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed typo/grammatical error.
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5055:
> 
>> 5053:         @Override
>> 5054:         public boolean format(DateTimePrintContext context, StringBuilder buf) {
>> 5055:             Long value = context.getValue(MINUTE_OF_DAY);
> 
> This does not match the spec: " During formatting, the day period is obtained from {@code HOUR_OF_DAY}, and optionally {@code MINUTE_OF_HOUR} if exist"
> 
> It is possible and legal to create a Temporal that returns `HOUR_OF_DAY` and `MINUTE_OF_HOUR` but not `MINUTE_OF_DAY`. As such, this method must be changed to follow the spec.
> 
> -----
> 
> In addition, it is possible for `HOUR_OF_DAY` and `MINUTE_OF_HOUR` to be outside their normal bounds. The right behaviour would be to combine the two fields within this method, and then use mod to get the value into the range 0 to 1440 before calling `dayPeriod.include`. (While the fall back behaviour below does cover this, it would be better to do what I propose here.)
> 
> An example of this is a `TransportTime` class where the day runs from 03:00 to 27:00 each day (because trains run after midnight for no extra cost to the passenger, and it is more convenient for the operator to treat the date that way). A `TransportTime` of 26:30 should still resolve to "night1" rather than fall back to "am".

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/938