Round displayed weather forecast average temperatures (in month / week view cells) to integers precision
Okay, I know this might sound crazy because I'm basically asking for "less precision" here, but in the specific case of day cells in the month view's grid and in the week view's day headers area, this level of precision (1 digit after the period) doesn't really make sense:
- It uses 2 extra characters, which consumes space, which might be at a premium (like in issue #856)
- The number is meant to be an average of the whole daytime temperatures (even though it currently isn't), which... would make no sense to show with float precision, because any day, pretty much anywhere on Earth, is typically going to have a variation of at least 5 to 10 degrees (whether Celsius or Farenheit) between morning, noon and evening (not to mention night), so how can you show decimal numbers when the variation is so big?
- Even when temperatures are small numbers oscillating around 0 degrees celsius ±5 degrees, and even in the theoretical scenario where there would be a very small spread (let's imagine the theoretical scenario where the temperature throughout the day is precisely between 3 and 4 degrees Celsius), decimal precision does not make sense from a "human experience" standpoint, outside of a laboratory measuring a surface with an infrared thermometer... because we humans basically can't really tell a <1.5 degree difference outside. We can feel a 3+ degrees difference maybe, but not 0.5 degrees for sure (let alone 0.1), it's too similar (and influenced by too many other variables like wind, humidity, shade vs direct sunlight, etc.), so decimals are meaningless in practice for what the day will "feel like".
- When looking at a rough "very approximative" forecast like what would be seen in a calendar app, we're not necessarily looking for absolute precision, just a rough idea of how a day compares to another.
Therefore my suggestion would be that for the average temperature (or even if we provided two numbers, low vs high) label, in the month/week view frontend, we should round to the nearest integer. So for example, the temperatures shown in the above screenshot would become: 0 °C, 3 °C, -3 °C, 2 °C, 3 °C. In the backend (and calculations) however, we should retain float precision throughout, of course.
If we eventually show detailed information in a GtkTooltip on hover, then yeah for those more specific data points in the tooltip we could use more precision... but for the sake of the ultra-simple number in week/month view, I think it is misleading to provide decimals.