Justify why we prefer watts over kilowatts in the UK

[mcooley]

See this discussion in UnitConverterDataLoader.cpp. We currently prefer to use "Watts" instead of "Kilowatts" on devices in the UK region. We don't have any remaining documentation on why this choice was made (it's been around since 2013).

We should understand why watts might be preferred over kilowatts in this region and add a comment to the code, or make the logic work like the rest of the world if we don't have a good justification.

[mcfedr]

as a brit, certainly i'd expect anything less than 1kW to be in watts, not sure if this flag is relevant in that case or not, - e.g. a 100W light bulb, not a 0.1kW one. but for larger numbers, not sure I have an opinion.

[MicrosoftIssueBot]

This is your friendly Microsoft Issue Bot. I've seen this issue come in and have gone to tell a human about it.

[jsoref]

@mcfedr: That tendency applies in the US as well, and clearly does not explain how the Calculator treats the UK differently from the US.

I think in theory the question is roughly "when you talk about energy in general do you talk about <>?". I envision talking about kW (en-US/en-CA).

Note: when talking about power plants/municipalities, I would scale to MW/GW.

[jamierocks]

Presumably because Watt is the SI derived unit for power, which most of the world has adopted. Seems like it may be worth swapping this around so the USA is special-cased?

Either way, I prefer it starting from the Watt here in the United Kingdom. 👍

[MovGP0]

W is an SI unit. kW is a derivate. So I guess starting with W would be a logical choice. The only exception is to start with kg instead of g.

[jsoref]

It occurs to me that one reason the US is using kW is that the conversion to HP makes more sense (similar scale) vs W to HP.

[jsoref]

The items on a similar same scale to Watts are Foot-pounds/minute and BTUs/minute. @mcfedr , @jamierocks, @MovGP0: How frequently do you use either of those/and which (including in primary school...)?

[jamierocks]

The only exception is to start with kg instead of g

Slightly offtopic, but kilogram is the actual base unit so that's not really an exception. Watt is also a derived unit too, from the Netwton, metre, and second (Nm/s).

[jamierocks]

@jsoref Never used Foot-pounds/minute or BTUs/minute - nor do I have an idea what pounds or BTUs are (I believe feet were the length of a kings foot?).

I was only ever taught in SI units, though occasionally I've seen maths questions that use miles-per-hour - though that kinda makes sense, as our roads still use mph.

[jsoref]

It might or might not be obvious, but unit conversions are only useful if users have occasion to use a pair of units. A calculator is not needed to convert kW to W.

If people live in a purely SI world then a large portion of the calculator's unit conversions:

• Volume (m³)
• Length (m)
• Weight and Mass (kg)
• Temperature (K) -- albeit °C
• Energy (J) -- you can find BTU there
• Area (m²) -- albeit converting 1km² to 1e6 m² might be...
• Speed (m/s) -- albeit km/h ~ m/s
• Power (W)
• Data (...)
• Pressure (Pa)
• Angle (rad) -- albeit deg

... are useless.

Thus the question in some respect is: "Which non-SI units are users likely to being using?"

Slightly offtopic: I can't convert from angstrom to lightyear (this is sad) -- the closest I can get more or less is meters to nanometers.

[jamierocks]

Absolutely, kinda missed the point on that comment. Common non-SI units in the UK are:

• Miles (roads)
• Pint (milk)
• Stone (mass)
• Feet + Inches (height)

Kelvin is the SI for temperature - I'm guessing calculator already handles that (I'm not at a windows machine to check I'm afraid).

Though having ones commonly used in the USA is totally useful as well - for example recipes, which are like deciphering ancient Egyptian texts.

[jsoref]

Yes, it handles K. For reference, here's a way to see the units it more or less handles: https://github.com/Microsoft/calculator/blob/master/src/CalcViewModel/DataLoaders/UnitConverterDataConstants.h

[MovGP0]

The only exception is to start with kg instead of g

Slightly offtopic, but kilogram is the actual base unit so that's not really an exception.

I know. Except you use the cgs system 😅 But in that case the cm is the exception to the rule of not having a prefix to the base unit.

[MovGP0]

• Temperature (K) -- albeit C
• Data (...)
• Angle (rad) -- albeit deg

1. The temperature unit is not C (Coloumb) and also not ° (angular-degree), but °C (degrees celsius). The degrees prefix (°) is an indicator that it's a relative unit; temperature units with a ° should be seen as a postfix function that converts to K (kelvins):

   { °C(r) ↦ (r + 273.15) ⋅ K | r ∈ ℝ }

This means that when subtracting two thermodynamic temperatures, which are given in °C, you always get the difference in K, since °C does not make sense here mathematically/physically.

Most people don't understand that, so the SI defined the exception that people can write °C, but you need to think about it as K, which I think makes it even more confusing.

Sidenote: Always when I'm hearing a news anchor or news article talk about global warming and gives the average temperature risen in °C, my back is tingeling and I'm screaming internally 'no you idiot, it's called kelvins'. The proper use of units clearly separate the laymen from the experts here.

2. The physical dimension for data is the entropy S, which has the SI unit kg⋅m²⋅s⁻²⋅K⁻¹. But as a non-physicist, you can also call it 'bit' instead.

3. Note that gon (400 gon = 2π rad) is a totally different unit than ° (356° = 2π rad). There is also the military definition of a ' (3600' = 2π rad). I am unsure why the Windows calculator writes 'grad' instead of 'gon', since people tend to confuse 'grad' with '°' (ie. in german, the sign ° is spoken 'grad'). Also would prefer to have the scientific calculator in rad-mode per default; especially since there is already a π-symbol on it.

See Liste physikalischer Größen for further reference (unfortunately, the english version of this article is not as good).

[grochocki]

There is great conversation here about decisions around unit converters. Closing this as a duplicate of #515, where we are exploring a more comprehensive review of our strategy in this feature area.