How to handle {hours: 'numeric', minutes: 'long'} ?

[justingrant]

What happens with weird styles like {hours: 'numeric', minutes: 'long'}? Should it throw? Does 'long' get "upgraded" to '2-digit' like 'numeric' would have been? Does 'numeric' get upgraded to 'long'? Something else?

(from #66 (comment))

[sffc]

Related: #64 (comment)

Here is the rule I suggested there:

1. "hour", "minute", and "second" must be either all "numeric" or all not "numeric".
   • We could weaken this rule, but maybe it's good to start strict.
2. If "millisecond" is "numeric", then "microsecond" must also be "numeric".
3. If "microsecond" is "numeric", then "nanosecond" must also be "numeric".

[justingrant]

1. "hour", "minute", and "second" must be either all "numeric" or all not "numeric".

What about '2-digit'?

2. If "millisecond" is "numeric", then "microsecond" must also be "numeric".

Would we also need a rule for second->millisecond? eg. If "second" is "numeric", then "millisecond" must also be "numeric".

[sffc]

Okay, how about if we just ensure that no alpha-type style (long, short, narrow) can be followed by a numeric-type style (numeric, 2-digit). Example pseudo-code algorithm:

1. Let fields_to_check be [nanosecond, microsecond, millisecond, second, minute, hour].
2. For i in 0 to fields_to_check.length:
   1. If field_values[fields_to_check[i]] in (numeric, 2-digit):
      1. Let i_type be "numeric"
   2. Else,
      1. Let i_type be "alpha"
   3. For j in i+1 to fields_to_check.length:
      1. If field_values[fields_to_check[j]] in (numeric, 2-digit):
         1. Let j_type be "numeric"
      2. Else,
         1. Let j_type be "alpha"
      3. If i_type is "alpha" and j_type is "numeric", throw RangeError.

[ryzokuken]

I am assuming consensus on this as long as we don't have any objections: numeric type styles can only be followed by other numeric type styles. This is already a part of the spec PR at #68

[ryzokuken]

This has been addressed by the PR at #68. Closing.