String formatting of Temperature, Pressure and future physical quantities

[pgrawehr]

While working on the WeatherHelper stuff, I found that it was pretty inconvenient that the Temperature struct did not have a ToString() member. So I added one, and also added a public string ToString(string formatArgs, IFormatProvider culture) method, that takes formatting arguments to print Temperature in different units.

With PR #1046 it is now proposed to do the same for Pressure, but there are a lot of possible ways one may want to format such values, so we need a general concept on how to create such formatting members and what kind of formatting options should be supported.

As a reference, the two proposed ToString() functions for Temperature and Pressure:

        /// <summary>
        /// Returns the string representation of this pressure, with the given format string and using the given culture.
        /// Valid format specifiers are:
        /// PA: Pascal
        /// MBAR: Millibar
        /// KPA: Kilopascal
        /// HPA: Hectopascal
        /// INHG: Inch of mercury
        /// MMHG: Millimeter of mercury
        /// An extra number defines the number of decimal digits to use (default 1)
        /// <example>
        /// <code>
        /// var s = p.ToString("PA2"); -> "101325.01 Pa"
        /// var s = p.ToString("HPA2"); --> "1013.25 hPa"
        /// </code>
        /// </example>
        /// </summary>
        /// <param name="formatArgs">Format string</param>
        /// <param name="culture">Culture to use. Affects the format of the number.</param>
        /// <returns>String representation</returns>
        public string ToString(string formatArgs, IFormatProvider culture)

        /// <summary>
        /// Returns the string representation of this temperature, with the given format string and using the given culture.
        /// Valid format specifiers are:
        /// C: Degrees celsius
        /// F: Degrees Fahrenheit
        /// K: Degrees Kelvin
        /// An extra number defines the number of decimal digits to use (default 1)
        /// <example>
        /// <code>
        /// var s = t.ToString("K2"); -> "293.36°K"
        /// var s = t.ToString("C"); --> "20.21°C"
        /// </code>
        /// </example>
        /// </summary>
        /// <param name="formatArgs">Format string</param>
        /// <param name="culture">Culture to use. Affects the format of the number.</param>
        /// <returns>String representation</returns>
        public string ToString(string formatArgs, IFormatProvider culture)

Questions include:

• Should such formatting members generally be included or not?
• How would one specify the unit?
• Do we need to make the space between unit and number changeable?
• May the unit name be culture-dependent? (I don't know how a temperature is written in China)

I guess that including a standard formatting for the parameterless ToString() is less disputed and should be done in either case.

CC: @MarkCiliaVincenti @krwq

[krwq]

cc: @tarekgh

[krwq]

Some open questions:

• how would user remove space between unit and number?
• are units translated/spelled the same in all languages?
• are there languages (i.e. some where you type right to left) where number would go second, if so how would user swap the order?

[krwq]

Also:

• How would user specify if they prefer to display degrees character?
• [future thinking even if out of scope for now] How would user specify if they prefer to display full unit name? How would it be translated? (ICU might support that)
• Should ToString() figure out the default unit for the current culture and use it instead of our default?

[krwq]

If possible we should reuse NumberFormatInfo here, perhaps this should work very similar to currency formatting (per @tarekgh offline suggestion):
https://docs.microsoft.com/en-us/dotnet/standard/base-types/standard-numeric-format-strings#the-currency-c-format-specifier

Note we can also propose a feature in NumberFormatInfo if we can't re-use it right now

[tarekgh]

I support taking advantage of NumberFormatInfo even it lacks support for temperature and Pressure which we may add later to the framework. but at least we can use it for format the number (using the separators and decimal points) and we always append the unit at the end for now.

[MarkCiliaVincenti]

I'm actually proud I opened a can of worms :) I will give my feedback later.

[pgrawehr]

If internally using ToString("F"), NumberFormatInfo is being used implicitly. The implementation already properly decides between . and , for instance.

[tarekgh]

If internally using ToString("F"), NumberFormatInfo is being used implicitly. The implementation already properly decides between . and , for instance.

Yes, you are right. I was hoping not introducing special format inside Temperature and Pressure types and have the formatting standardized in the cultures (in NumberFormatInfo) as we do for currency and other numbers.

[krwq]

@tarekgh there are some unit multipliers which might be problematic without being a bit more explicit, i.e. Hectopascal vs Pascal - depending on the usage you might or not want the multiplier but inch vs mm of hg/K or C on the other hand is something which I agree can be related to culture

[tarekgh]

there are some unit multipliers which might be problematic without being a bit more explicit, i.e. Hectopascal vs Pascal - depending on the usage you might or not want the multiplier but inch vs mm of hg/K or C on the other hand is something which I agree can be related to culture

The unit shouldn't specified in the format :-) if cultures support temperature and pressure units, then users can pass the culture to get the format for the matched units as desired. think about it as how we handle currency today.

[pgrawehr]

What krwq means: For some quantities, the default unit is clear. For temperature, it's Fahrenheit in the US and Celsius everywhere else. But for others it's not so clear: For pressure, it depends on context whether you want mmHG/inchHG or Bar/Pascal/Hectopascal. Or for speed, it might normally be Kilometers/hour vs Miles/hour, except if you are into aviatics or shipping, where it would be knots. And for physicans, it's meters/second (which is the SI unit for it).

[pgrawehr]

Related: #869 and the question, which units (or actually more precise: which physical quantities) shall have their own class representation.