Seasons in OH Astro Binding

[carryonrewardless]

Until I made use of the Season Name in the amazing astro binding I didn’t realise that Australia was seemingly alone in starting seasons not on the equinox or solstice but on the first of the month and each season with a 3 month duration. I.e Spring starts 1st September Summer starts 1st December Autumn starts 1st March Winter starts 1st June

It’s not the highest priority but perhaps the Location item can be detected in the Binding to set Season Name for us Down Under.

Further info: It may be that Sth America observes the Aussie convention as some searches I made refer to the various seasons “beginning in” March, June, September and December. It does seem that New Zealand follows the Equinox/Solstice convention with a small variation. According to https://seasonsyear.com/South-Africa2 , “Spring in South Africa starts in August”. So there are quite a few variations.

[triller-telekom]

@sjka @htreu Can you please add a "help wanted" tag to this issue?

[lukiep]

I realise this is quite old, but I wanted to add my voice here that this update is still desired.

Due to the great variance in season dates across countries, maybe an alternative to hard coding the season dates would be for each user to set the dates in the binding configuration. If no dates are entered the binding uses the current default, otherwise use the user-entered dates.

[Hilbrand]

Looks like this can be defined as astronomical seasons vs meteorological seasons. The latter start at the first of the month. This could be implemented by adding a thing configuration parameter: useMeteorologicalSeason.

(Some notes about how this could be implemented I once gave): This variable should be passed to SeasonCalc.getSeason. In that method it calls calcEquiSol. For the meteorological season it should just make a different calculation. So best wrap that method and implement something like. So replace the calls to calcEquiSol with calcSol:

private Calendar calcSol(int season, int year, boolean useMeteorologicalSeason) {
  return useMeteorologicalSeason ? calcMeteoSol(season) : calcEquiSol(season, year); 
}

calcMeteoSol can just use a switch statement to return the start date of the month of the given season.

Adding to AstroThingConfig is enough. Pass the useMeteorologicalSeason in the same way the latitude is passed.

[clinique]

This seems indeed the best approach. Took the opportunity to inform myself on this, I learned that some countries also use a different system where Spring start the first month having average temp above 0°C ! Don't you think that it should be stored at core level if a given country uses astronomical or meteorological seasons ?

[Hilbrand]

should be stored at core level

I'm not sure what you mean by taht? For example the user can select from a list countries? Where each country is bound to the way they identify seasons?

I didn't want to make it a binding global configuration in order to still have the ability to create things that show different seasons. If someone wants to display different seasons for different counties.

[clinique]

The core already store the installation country. We could have an extra data that identify wether it uses meteorological or astronomical seasons (like currently done regarding UoM for Metric/Imperial). This would provide a default value to Astro, that could be overriden.

[Hilbrand]

Country could be used to set the default. I didn't find a complete list, on wikipedia It mentions: Australia, New Zealand, Pakistan and Russia