Degree Days

Weather Data for Energy Professionals

This page explains how Degree Days.net calculates degree days. If you just want heating or cooling degree-day data, there's probably no need to understand the calculation processes in detail - just use Degree Days.net to calculate the degree days for you. But you might find our answers to these calculation-related questions useful if you're curious, or deciding whether to get your degree days from here or another source, or if you're comparing data from our system with data from elsewhere.

To calculate degree days we start with temperature data. But the type of temperature data we use, and the process we use to calculate degree days from that temperature data, depends on the weather station:

- For weather stations that are shown with a bar and stars (see right) - all the airport ICAO and WMO stations and the higher-quality personal weather stations - we use detailed temperature readings taken throughout each day, turning them into degree days using the Integration Method that is introduced in this Google Knol about degree days and explained in more detail further down on this page. We call it the "Integration Method" because, mathematically, integration is how it works. It's an intensive calculation process, but it's the best method we know of for accuracy of the resulting degree-day data.
**We use the Integration Method for the vast majority of data that our system generates**, and it is the only method our API* will use to supply data for longitude/latitude positions or postal/zip codes. - For the lesser-used weather stations that don't have a bar and stars - the lower-quality personal weather stations - we use daily average, maximum, and minimum temperatures, and turn them into degree days using an enhanced version of a set of equations developed by the UK Meteorological Office. We refer to the original UK Meteorological Office Equations as the "Met Office Method", and the enhanced version as the "Enhanced Met Office Method". This method gives a pretty good approximation of the Integration Method - about as good as we could hope for using daily average/maximum/minimum temperatures.

**The Degree Days.net API provides an automated way for software to get large quantities of data out of our system. You can fetch data from any station ID, but you can also specify longitude/latitude positions or postal/zip codes and let the API select stations for you automatically. The API will only ever select stations for which we use the Integration Method.*

The Integration Method accurately accounts for temperature variations within each day as well as temperature variations from one day to the next. It is how degree days were originally defined and it correlates better with the heating/cooling energy consumption of modern thermostatically-controlled HVAC systems (which vary their output as the temperature changes throughout each day).

Why is it important to consider the temperature variations within each day? Well, consider the simple example of a hot day and a cold night... The average outside air temperature over a day might be a comfortable 65°F (18.5°C), but, beneath that average, it could have risen to 85°F (29.5°C) in the early afternoon and dropped to 45°F (7°C) at night... One can't reasonably argue that a typical building would not need any heating or cooling on a day like that! (Though one can reasonably argue about the correct base temperature(s) of any particular building, and that is an important factor to consider.)

The approximation methods either simplistically pretend that within-day temperature variations don't matter, or they try to estimate them from daily average/maximum/minimum temperatures. The Integration Method is best because it uses detailed within-day temperature readings to account for within-day temperature variations accurately.

It depends on the weather station. We use the full detail of the temperature data available. For most airport ICAO and WMO weather stations, temperature readings are taken roughly* every 30 or 60 minutes. Some stations at very small airports and remote locations record less frequently, some stations record 3 or more times per hour.

**Many weather-data providers show detailed temperature readings as perfectly-regular hourly figures. But such data is rarely an accurate representation of the temperature readings that were originally recorded by the weather station. For example, airport weather stations typically record a little before the hour rather than on the hour, and they often miss readings, submit erroneous readings, or take additional readings when conditions change quickly. Some airports record more or less frequently than hourly. Perfectly regular hourly or half-hourly temperature data has usually been interpolated into that format. For our Integration-Method calculations we use the raw temperature readings exactly as they were recorded by the weather station. This makes our degree days a little more accurate than they would be if we calculated them from interpolated data.*

If temperature readings were perfect, then more frequent readings would always make for more accurate degree days. However, temperature readings are never that accurate. Automated weather-station thermometers often output data to the nearest 0.1 degree (whether in Fahrenheit or Celsius), but typical estimates put the accuracy of a thermometer reading at around ±0.5°C at best. ±0.5°C (one-sigma) is the estimated precision that is published in the NWS guide for ASOS weather-station equipment (used by many of the high-quality airport weather stations in our system). You will also see similar values quoted in research papers and the manuals for other weather-station equipment.

If the ±0.5°C (or thereabouts) were all random error, then accuracy could be improved by averaging lots of temperature readings together (roughly similar to what degree-day calculations do). Good weather-station equipment (like the ASOS equipment) already works to reduce random errors as the published temperature readings are based on a rolling average of observations taken over the few minutes preceding. But much of the inaccuracy in published temperature readings comes from systematic errors, which don't cancel out on averaging. Systematic errors would affect the degree days even if weather stations took an *infinite* number of temperature readings.

Our testing shows that the inaccuracy introduced into degree days by having 60-minute temperature readings as opposed to much more frequent readings is very small compared to the inaccuracy introduced by the temperature readings themselves. Our tests put it at around ±0.05°F or ±0.03°C (one-sigma) i.e. pretty much irrelevant.

When there are larger gaps between temperature readings, Degree Days.net interpolates the temperature variation between and assigns the calculated degree days a "% estimated" figure indicating the approximate extent to which the interpolation affected accuracy. These "% estimated" figures are useful as a relative measure for choosing which weather stations to collect data from, but the figures themselves are subject to change and should not be considered a reliable indication of overall accuracy.

The Integration Method is conceptually simple, but implementing it precisely with real-world data is more complicated. We can't practically detail the minutiae of the exact algorithm that our system uses, but we will try to give a clear overview of the calculation process.

Our system will happily calculate HDD and CDD in Celsius or Fahrenheit, and in any base temperatures you choose. Fahrenheit-based degree days are typically used in the US, Celsius-based degree days are the norm in the rest of the world.

First, we'll give a simple example of calculating Celsius-based heating degree days for a spring day (2019-03-29) at station CXTO in Toronto, Canada. We're using a base temperature of 14°C but you should choose the heating base temperature that makes most sense for your building.

This example is simple because:

- The temperature data reported by the weather station on the day is exactly hourly. (As explained further above, although weather stations typically record the temperature once or more per hour, it's surprisingly rare for them to record exactly on the hour every hour. Data that is exactly hourly has almost always been interpolated into that format.)
- At no point did the temperature cross our chosen base temperature. This makes it easier to calculate the area between the temperature and the base temperature (which is effectively what we are doing when we calculate degree days using the Integration Method).

To get the data and chart above, we:

- Assemble all the temperature readings for the day in question, in the time zone of the station that they came from (weather stations typically report in UTC time so we have to convert the times to the local time zone).
- Remove any temperature readings that look likely to be erroneous. (All were fine in this case.)
- Assume a linear pattern of temperature change between each recorded temperature (effectively drawing a straight line between each point on the chart).

Then, for each consecutive pair of temperature readings, we:

- Calculate the time (in days) over which the temperature was below the base temperature. In this simple example this is always an hour (
`1/24`

days). - Calculate the average number of degrees by which the temperature was below the base temperature over the calculated time period (1). In this simple example this is always the base temperature minus the average of the two recorded temperatures.
- Multiply the time (1) and the temperature difference (2) to get the heating degree days for the period between the two temperature readings (an hour in this case).

Finally we sum all the figures (3) above to get the total heating degree days for the day.

Next we'll give a more complicated example of calculating Fahrenheit-based cooling degree days for a summer day (2019-06-07) at station KGNC in Texas, US. We're using a base temperature of 70°F but you should choose an appropriate cooling base temperature for your building.

On this day station KGNC recorded the temperature on the 15th, 35th, and 55th minute of each hour. It is very common for stations to have a regular-but-off-the-hour reporting pattern like this (but rarely exactly the same as there is a lot of variation between stations). Many stations vary their reporting times too, and sometimes throw in extra readings between the regular ones. More temperature readings make for more accurate degree days (though realistically the improvement over hourly temperature data is minimal), but they also complicate the calculation process.

The process of assembling the data and chart above is the same as for the heating degree days example above, except, because we don't have midnight temperature readings to precisely mark the start and end of the day, we also include the last temperature reading from the previous day (23:55 on 2019-06-06) and the first temperature reading from the following day (00:15 on 2019-06-08). We use these temperature readings to interpolate the two midnight temperatures.

Then, for each consecutive pair of temperatures within our day of interest (including the interpolated midnight temperatures described above), we:

- Calculate the time (in days) over which the temperature was above the base temperature on the day in question. For some periods this is zero because the temperature was below the base temperature. For many of the 20-minute periods in this example this is
`20/(24*60)`

but we have shorter gaps at the start and end of the day (00:00 to 00:15 and 23:55 to 00:00 on the next day). Also, for periods where the two measured temperatures are either side of the base temperature, we have to interpolate the time at which the temperature actually crossed the base temperature. - Calculate the average number of degrees by which the temperature was above the base temperature over the calculated time period (1).
- Multiply the time (1) and the temperature difference (2) to get the cooling degree days for the period.

Finally we sum all the figures (3) above to get the total cooling degree days for the day.

Other stations and other days present other complications such as erroneous temperature readings, longer gaps between readings (which we fill with estimates), badly-formed sometimes-ambiguous weather reports, clock changes (on days going into or out of Daylight Savings Time), and small inaccuracies that can sometimes arise as a result of the limitations of floating-point arithmetic. Our system has been programmed to deal with all of these complications as best it can, but there is always room for improvement - the bottom line is that calculating accurate degree days is a lot more complicated than it seems on the surface!

In the early days of degree-day-based analysis, approximation methods based on daily max/min temperatures were necessary for practical reasons. There just wasn't the technology to practically store and process all the detailed temperature data that is necessary to calculate degree days using the Integration Method. And weather stations weren't fully automated then either, so detailed temperature recording was less common, and many temperature records came from daily readings of maximum-minimum thermometers instead.

Technology has progressed hugely since then, but the approximation methods have lingered on, partly thanks to inertia, and partly thanks to the fact that, even today, using the Integration Method requires more programming and more server resources, both of which are expensive. Many sources of degree-day data are generalist weather-data providers for whom degree days are just a niche add-on that doesn't warrant the attention that a specialist provider can give them.

There's also a lot of misinformation out there. Search the web for "degree days" and you'll often see an approximation method being presented as *"how degree days are calculated"* without mention of the fact that it's just the approach (or one of the approaches) that was traditionally used in the author's country of origin.

All in all this has made things rather complicated. Many sources of degree days don't even tell you how they calculate their data, which makes it hard to compare data from one source with another. And degree days are used widely for global academic research and by multinationals tracking energy consumption across their locations worldwide (we know this because many academics and multinationals use our desktop app / API)... It wouldn't make sense for such analysis to use data calculated with a different approximation method in each country, some underestimating the real degree days, others overestimating. Much better to use the most accurate method possible for all locations.

Things are changing, fortunately. We use the Integration Method for the vast majority of our calculations, and we suspect we are the most widely-used source of degree-day data in existence today. There's no longer a need for people to use local-only data sources or generalist weather-data providers with inaccurate (and often unspecified) calculation methods. Our data being used and referenced so widely, for everything from building energy monitoring to global academic research, is helping to standardize the accurate Integration Method and phase out the various outdated approximation methods.

We've been using the Integration Method for the higher-quality weather stations, the ones that matter most, since August 2011. We use the Integration Method to calculate all the data from these stations (including data covering periods before 2011). We generally advise people to stick to these stations, and they are the only stations that our API will ever select automatically (if you ask it to supply degree days for longitude/latitude positions or postal/zip codes).

Ideally we'd use the Integration Method for all the lower-quality weather stations too, but there are technical obstacles that make this impractical at the moment. A little background is necessary to explain this...

Degree Days.net calculates degree days live. You tell Degree Days.net what data you want, and, while you wait, Degree Days.net assembles the appropriate temperature data and uses it to calculate the degree days you requested. Live data calculation is the only way we can practically offer data with a wide range of customizable base temperatures and breakdowns.

But live data calculation is an intensive process, particularly when using the Integration Method. To calculate a typical set of degree days using the Integration Method our system has to access and churn through many thousands (often millions) of temperature readings.

When we first built Degree Days.net, in Spring 2008, it used an approximation method that aimed to replicate the Integration Method as closely as possible using daily average/maximum/minimum temperatures. At the time, we didn't think it was feasible to use the full Integration Method on detailed temperature readings, not for live calculations anyway. And, given that the calculation method we were using was a pretty good approximation of the Integration Method, we considered live calculations (and the extensive calculation options they enabled) to be more important than using the Integration Method itself.

However, towards the end of 2010 we came up with a new and improved system design. And we started work on building a database of detailed temperature data. We carefully designed and optimized this storage system to enable fast access to long periods of detailed temperature data. Slowly, station by station, we filled this database with detailed temperature data. And we put systems in place to keep it up to date with fresh detailed temperature data, as it became available.

With this optimized database of detailed temperature data it was finally practical for us calculate degree days live using the Integration Method. After much work, we launched this new calculation system in August 2011.

The optimized database holds detailed temperature data for all of the airport ICAO and WMO weather stations, and the higher-quality personal weather stations. If a weather station is listed on our website with a bar and stars next to it (even if they're grayed out), then its degree days will be calculated using the Integration Method and detailed temperature data from the optimized database. If a station isn't listed with a bar and stars, its degree days will be calculated using daily average/maximum/minimum temperatures instead.

In an ideal world we would fill the optimized database with detailed temperature data from the remaining personal weather stations so we could use the Integration Method exclusively. But there are a lot of personal weather stations, and the vast majority have low-quality data that isn't much good for degree-day calculations. Our database is already very large, and adding a lot of low-quality data would slow the system down and make it harder to manage, so for practical reasons we need to draw the line somewhere. However, if you know of any high-quality personal weather stations that we're not already using the Integration Method for, let us know and we'll see if we can add their detailed temperature data into the optimized database.

As mentioned above, we use the accurate Integration Method (based on detailed temperature data) for all the airport ICAO and WMO stations in our system, and for the higher-quality personal weather stations too. We encourage people to stick to these stations, and they are the only stations that our API will ever select automatically when supplying degree days for longitude/latitude positions or postal/zip codes.

But, although the Integration Method is the best calculation method for accuracy of the resulting data, and the one that we use for the vast majority of *our* calculations, many other sources (especially non-specialist sources) calculate degree days using an approximation method based on daily summary data (some or all of daily average, maximum, and minimum temperatures). We also use an approximation method, the "Enhanced Met Office Method", to calculate degree days for the lower-quality personal weather stations in our system.

There are three popular methods for approximating degree days from daily temperature data:

The first two are both known as the "Mean Temperature Method". They approximate the degree days for each day using the average temperature for the day. For HDD they subtract the average temperature from the base temperature (taking zero if the average temperature is greater than the base temperature on that day). For CDD they subtract the base temperature from the average temperature (taking zero if the base temperature is greater than the average temperature).

This sounds like one method, but it's actually two because there are two commonly-used ways to calculate the average temperature for each day, both of which give slightly different results:

- The average temperature is taken to be half way between the maximum and the minimum temperatures on each day.
- The average temperature is calculated from detailed readings taken throughout each day (this method gives a more accurate average temperature).

The third is the Met Office Method - a set of equations that aim to approximate the Integration Method using daily max/min temperatures only. They work on the assumption that temperatures follow a partial sine-curve pattern between their daily maximum and minimum values. This is the method that our calculations for the lower-quality personal weather stations are based on (although we use an enhanced version - more on this in a moment).

First and foremost, we think it's best to use the accurate Integration Method over any of the approximation methods. We use the Integration Method for the vast majority of our calculations. But, when forced to use an approximation method (as we are for the lower-quality personal weather stations in our system), it makes sense to choose a good one.

The Mean Temperature Method is a popular approximation method, but we suspect this is primarily because it involves such simple calculations - it's simple to explain, simple to understand, and, given the necessary temperature readings, pretty much *anyone* could use it to calculate degree days (approximately).

Of the two approaches to the Mean Temperature Method, the one that uses accurate daily average temperatures is better than the one that approximates them as the midpoint between the daily maximum and minimum temperatures. But both variations of the Mean Temperature Method have a fundamental flaw: they assume that, on any given day, the heating or cooling in a building is either switched on or off. This *might* have been a reasonable approximation years ago, when heating systems were controlled manually, but it's not appropriate now, when most buildings have thermostat-based control systems that monitor the indoor temperature and switch the heating and cooling on and off accordingly.

The Met Office Method partly addresses this limitation by approximating for temperature variations that occur *within* days. This is relevant for days on which the heating or cooling was only needed for *part* of the day.

The Enhanced Met Office Method improves slightly upon the original Met Office Method. Whilst the original Met Office Method approximates the daily average temperature by taking the point half way between the daily maximum and minimum temperatures, the Enhanced Met Office Method uses the real daily average temperature (calculated from temperature readings taken throughout the day) instead of this approximation.

In summary, we think the Met Office Method is better than the Mean Temperature Method, and the Enhanced Met Office Method is a minor improvement that makes the Met Office Method a little better again. So we use the Enhanced Met Office Method to calculate degree days for the lower-quality personal weather stations in our system. But the accurate Integration Method is better than all of the approximation methods, and that is what we use for the vast majority of our calculations (for the airport ICAO and WMO stations and the higher-quality personal weather stations).

On days when the outside air temperature *doesn't* cross the base temperature:

- The Integration Method (using as much temperature data as is available), the Enhanced Met Office Method, and the Mean Temperature Method using real averages, give almost-identical* figures. In other words they are all very accurate.
- The standard Met Office Method and the Mean Temperature Method that uses averages approximated from daily maximums and minimums both give identical figures. They're usually reasonably accurate, but not as accurate as they would be if they used real averages.

**We say "almost-identical" because to some extent it can depend on how the average temperature for each day is calculated. If it's a mean value calculated from good, regular readings, the resulting degree days (when the outside temperature doesn't cross the base temperature) will be identical to those calculated using the Integration Method. But the mean temperature can be distorted by erroneous readings that aren't correctly discarded before its calculation, and by irregular readings that represent one part of the day more densely than another (assuming the average isn't calculated as a weighted mean). These differences typically only have a small effect, but they do mean that data approximated using daily average temperatures often isn't quite as good as data calculated using the Integration Method, even when the outside temperature doesn't cross the base temperature.*

The choice of calculation method becomes much more important on days when the outside air temperature *does* cross the base temperature. On such days the Integration Method is the only one that is able to give an accurate result. The Met Office Methods aren't as good, but they do tend to do a better job than the Mean Temperature Methods.

On days when the outside air temperature crosses the base temperature, the accuracy of the Mean Temperature Method is typically very poor. For locations with temperatures that hover around the base temperature, the Mean Temperature Method will typically underestimate degree days significantly. The impact of this inaccuracy depends on the climate and the choice of base temperature.

The Integration Method is the method that the approximation methods try to emulate, and it is the one we use for the airport ICAO and WMO stations and the higher-quality personal weather stations in our system. It is best to favour that method (and those stations) whenever possible (which it usually is).

But, in certain circumstances, you might have no choice but to use data from another system that has been calculated using an approximation method, or data from one of the lower-quality personal weather stations in our system for which we use the Enhanced Met Office Method (a good approximation method, but an approximation method nonetheless).

If you live in a climate where the temperature spends a lot of time hovering around the base temperature, we would advise you to be sceptical of degree days calculated using the Mean Temperature Method. But beyond that, assuming you are using degree days for the same sorts of purposes as most people (analysis of your building's energy consumption in some shape or form), accurate data is best, but it is important to keep some perspective. If, for whatever reason, you are using data calculated with an approximation method, and you are concerned about the inaccuracies introduced by that approximation method, we suggest you:

- Read our "Degree Days - Handle with Care!" article and see how many of the sources of inaccuracy highlighted in that article apply to the calculations that you're doing.
- Try a few nearby weather stations to see how the data varies depending on the exact location that the temperatures are recorded from. (All else being equal, data from a station closer to your building is better than data from a station further away, but even small distances between weather-station locations can make a surprising difference to the recorded temperatures, and consequently to the degree days. Even if you had a weather station right next to your building, the figures it collected would be influenced by which side of the building it was located on!)
- Try calculating your degree days with a few nearby base temperatures (Degree Days.net has a little checkbox to make this easy to do), and notice how a small difference in base temperature makes a pretty big difference to the generated degree-day figures. Then ask yourself if you can be
*sure*you've picked the most appropriate base temperature for your building (bearing in mind that, as described in the article linked above, the base temperature of a building doesn't actually remain constant anyway).

Doing these things won't make your degree-day data any more accurate, but it will make it clear that degree-day-based analysis of energy consumption is unavoidably approximate, and that the approximation method used to calculate the degree days is typically only one of many sources of inaccuracy. The significance of the method that your degree days are calculated with will probably pale in comparison to your choice of base temperature, for example.

Most likely you're seeing what we call "recalculation differences". They're a side effect of the way that Degree Days.net calculates its data.

Degree Days.net calculates its degree-day data live, at the moment that you request it. Live calculation is good - it's what makes it possible for us to offer all the options for base temperature etc. It also means we can improve our calculation engine over time, safe in the knowledge that all data generated using that engine (whatever locations and periods it may cover) will be calculated using a consistent process.

But a side-effect of live calculation is that an update to our calculation engine can result in differences between data that you generated before and after the update was made. So you might occasionally notice recalculation differences if you generate a set of degree days, save it somewhere, and then compare it with data that you regenerate at a later date.

There are two main types of update that can cause such differences:

- We may tweak our processes for interpreting and checking the weather reports and temperature readings from the weather stations in our system. It's not uncommon for real-world weather stations to send reports with errors or ambiguous data, and we put a lot of development work into our system for interpreting and checking these inputs. If an update to our system changes its interpretation of a weather station's reports or the temperature data from those reports (e.g. if more or less erroneous reports/readings are identified than previously), the calculated degree days can change too. It is rare for these sorts of tweaks to result in significant re-calculation differences, but it can happen.
- We may improve the calculation process used to turn the temperature readings into degree-day data. This is not really relevant for the higher-quality stations for which we are using the Integration Method (most people are using these stations exclusively), as the only calculation improvements we could make to our implementation of the Integration Method are likely to be very small tweaks with negligible impact. However, if you happen to be using any of the lower-quality personal weather stations for which we are currently using the Enhanced Met Office Method, you should expect to see small but noticeable differences if/when we shift those stations over to the Integration Method. (Do note, however, that it is unlikely that you are using any of the lower-quality personal weather stations unless you have made a specific effort to target them.)

Finally, there can sometimes be a little volatility in the most recent data from a weather station, if some of its weather reports are delayed, or it sends corrections to replace erroneous weather reports that it sent previously. It's unusual for this sort of volatility to happen, and, on the rare occasions it does, it wouldn't usually affect more than the latest 10 or so days of data.

There are occasional cases where a station has been sending bad reports that an update to our system has significantly improved the handling of, but these are rare and probably not worth worrying about.

Volatility in recent data is unlikely to be worth worrying about either, but, if you are downloading data regularly, it makes sense to download just a little more data than you need to correct it if it happens.

We *don't* think it's worth worrying about small tweaks to the calculation process - they're unlikely to make any meaningful difference to the data or the calculations you're using it for.

Upgrading a weather station from the Enhanced Met Office Method to the Integration Method is more than a small tweak, however, and it *can* result in noticeable recalculation differences. But it is unlikely that this sort of upgrade would affect you:

- We've been using the Integration Method for all airport ICAO and WMO stations in our system since our big system upgrade in August 2011 (see further above for more on this). So for those stations only data downloaded before August 2011 could have used an approximation method. (For clarity, please note that once a station is set to use the Integration Method, that applies to all data downloaded for that station from that point forward, whether the data covers a period before the upgrade or after.)
- Our API has only ever used the higher-quality Integration-Method stations to provide data for longitude/latitude positions and postal/zip codes, so you can't be affected if that is how you are getting your data.

Essentially you can only be affected by an Enhanced-Met-Office-Method-to-Integration-Method upgrade if you have data stored that you downloaded before August 2011, or if you have been collecting data for a personal weather station by ID, and that station has since been upgraded to use the Integration Method. In these unusual cases it probably *would* make sense for you to re-generate and replace that previously-collected data. Data calculated using the Integration Method will be more accurate, and by re-generating the data you previously collected you can take advantage of that increased accuracy for your past data as well as your future data.

That said, we don't want to suggest that it is *necessary* to re-generate previously-collected data after a station's upgrade to the Integration Method. Degree Days.net has always used a robust, accurate calculation engine, so it's not as if your previously-collected figures aren't good, just that re-generated figures should be better. As we frequently point out, degree-day-based analysis is inherently approximate... It makes sense to use the most accurate data you can, but it's not worth obsessing over relatively small factors like recalculation differences when there are other sources of inaccuracy that are likely to be more significant in your analysis.

Yes, we've certainly thought about it.

Degree Days.net already offers heating degree days, cooling degree days, Celsius degree days, Fahrenheit degree days, and a huge range of possible base temperatures. It makes sense for us to offer all these options as there are strong practical reasons why people need to make use of them.

However, we've yet to be convinced that there would be any value in us offering a choice of calculation methods, especially since the alternatives would all be inferior to the methods that our site is using now (the Integration Method being the most accurate method that we are aware of for stations with detailed temperature records, and the Enhanced Met Office Method being the most accurate approximation method that we are aware of for calculating degree days from daily average/maximum/minimum data).

Plus we're reluctant to make degree days any more complicated for people than they are already...

That said, if there were an approximation method that improved upon the Enhanced Met Office Method, we'd certainly want to think about using it for the lower-quality stations that aren't yet using the Integration Method. We are in contact with academics that are researching degree-day-calculation methods - if you are also doing such research, we'd love to hear from you too.

Also please do email us if you particularly *would* like to see a range of calculation methods offered. Although we've explained our rationale for *not* offering such options at the moment, we'd welcome any persuasive arguments that we might be unaware of.