Calculating Degree Days

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.

How do you calculate degree days?

We calculate degree days from detailed temperature readings taken throughout each day, using the Integration Method that is introduced in this introduction to 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.

Why is the Integration Method best?

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.)

Some other sources (particularly generalist weather-data providers for whom degree days are not a focus) are still using outdated approximation methods that either simplistically pretend that within-day temperature variations don't matter, or they try to estimate them from daily average/maximum/minimum temperatures. We discuss these approximation methods in more detail further below, but, in a nutshell: the Integration Method is best because it uses detailed within-day temperature readings to account for within-day temperature variations accurately.

How frequent are the temperature readings you use for the Integration Method?

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 (as is usually the case for the high-quality hourly temperature data that we provide through our Pro website and API). 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.

How does the frequency of the temperature readings affect the accuracy of the degree days calculated using the Integration Method?

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.

How do you calculate degree days using the Integration Method?

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.

Simple example: calculating Celsius-based heating degree days from hourly data

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).

Simple example of calculating Celsius-based heating degree days with a base temperature of 14°C for a day with perfectly hourly temperature data

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:

1. 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).
2. 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.
3. 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.

Example of calculating Fahrenheit-based cooling degree days for a day on which the temperature crossed the base temperature

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.

Example of calculating Fahrenheit-based cooling degree days with a base temperature of 70°F

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:

1. 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.
2. Calculate the average number of degrees by which the temperature was above the base temperature over the calculated time period (1).
3. 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!

Why don't all sources of degree-day data use the Integration Method?

In the early days of degree-day 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 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 data from 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 accurate Integration Method, 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.

What are the main approximation methods that use daily temperature data instead of detailed temperature data?

Although the Integration Method is the most accurate degree-day-calculation method, and the one that we use, 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).

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:

1. The average temperature is taken to be half way between the maximum and the minimum temperatures on each day.
2. 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.

Another approximation method deserves mentioning: The Enhanced Met Office Method. This is based on the original Met Office Method, but, whilst the original Met Office Method approximates the daily average temperature by taking the midpoint 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). The daily maximum and minimum temperatures also play a role in approximating within-day temperature variations, as they do for the Met Office Method.

This covers the main approximation methods, but it doesn't cover them all, as quite a few countries have, in the past, developed their own traditional methods for approximating degree days from limited local temperature readings (usually daily maximum/minimum temperatures). Some countries even have multiple such methods! Given the abundance of detailed temperature data available now (which can be used to calculate degree days accurately), it is more difficult to justify using these approximation methods today, but some still linger on because of inertia and slow-to-modernize systems.

Which approximation method is best?

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 our calculations. But, when forced to use an approximation method, 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 as it incorporates the real daily average temperature (calculated from temperature readings taken throughout the day) as well as the daily maximum/minimum temperatures. In our early days, while we were developing the infrastructure necessary for us to use the Integration Method at scale (which we launched in August 2011), we actually used the Enhanced Met Office Method ourselves, because it gave a better approximation of the Integration Method than the alternatives. (Just to avoid confusion, if you fetch degree days from our system now, it will use the Integration Method for periods both before August 2011 and after.)

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. The other approximation methods vary, some do a better job of emulating the Integration Method than others. But all approximation methods are inferior to the Integration Method, as it is simply not possible to accurately model within-day temperature variations from limited temperature data like daily max/min temperatures. The weather is just too variable for any approximation method to work consistently well.

How do degree days calculated using the different methods compare?

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 some parts of the day more densely than others (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 method that will give an accurate result. The Met Office Methods are not 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.

Should I be concerned about inaccuracies introduced by approximation methods?

The Integration Method is the method that the approximation methods try to emulate, and it is best to use it whenever possible. But, in some circumstances, you might have no choice but to use degree days that have been calculated using an approximation method. For example you might be locked into a system that gets its degree days from a less-than-ideal source.

For buildings in climates where the temperature spends a lot of time hovering around a carefully-chosen base temperature, we would advise you to be sceptical of analysis done using degree days that were calculated with the Mean Temperature Method. But beyond that, assuming you are using degree days for the same sorts of purposes as most people (analysis of building energy consumption), it is helpful to keep some perspective. If you have read "Degree Days – Handle with Care!" you will appreciate that, unless your analysis is really thorough, less-than-ideal degree-day data is probably only one of many sources of inaccuracy. Its significance will probably pale in comparison to that of your choice of base temperature, for example.

That said, accurate data calculated using the Integration Method is definitely best, so it does make sense to use it whenever you can!

Why are the figures for period x slightly different to the figures I previously downloaded for the same period?

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 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 several types of update that could cause such differences:

• We may improve 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 degree days calculated for that weather station can change too. It is rare for these sorts of improvements to result in significant re-calculation differences, but it can happen.
• We may improve our processes for filling in gaps left by missing or erroneous temperature data. Such improvements would only affect stations that had gaps or errors in the first place, and any affected figures would be marked by non-zero "% estimated" values both before and after improvements.
• We may make minor improvements to our internal implementation of the Integration Method. Such improvements would have negligible overall impact, but small re-calculation differences may still arise. For example, in June 2019 we re-worked our internal implementation of the Integration Method to use exact fractional arithmetic (like 43/10 × 28/1440) rather than floating-point arithmetic (like 4.3 × 0.01944444444), as we had found that in certain cases the floating-point calculation of a daily degree-day value could result in a number like 8.3499999999 (which rounds to 8.3), whilst if we used fractional arithmetic for all intermediate steps, we'd finish with a perfectly accurate number like 167/20 or 8.35 (which rounds to 8.4). Most sane people would regard this as hair-splitting, but we are rather obsessive about data quality!

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 if it sends corrections to replace erroneous weather reports that it sent previously, or if its reporting has gaps that we need to fill with estimates (as we may be able to improve on those estimates after more good data has arrived from after the gap). This volatility in recent data is unusual in higher-quality weather stations with good star ratings, though it is more likely to happen for lower-quality stations. When it does happen, it wouldn't usually affect more than the latest 10 or so days of data.

How should I handle recalculation differences? Should I re-generate data that I have generated and stored previously?

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.

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

If you want to be exceedingly thorough, you could periodically re-download all your stored historical data, to make sure it was calculated with the latest algorithms (which should always be the best algorithms). But we think this would be overkill for the vast majority of people (and systems using our API).

Volatility in recent data shouldn't be a major concern, but, if you are downloading data regularly, it does make sense to download a little more data than you need (e.g. an extra month), to correct it if it happens.

Have you thought about offering a choice of calculation methods?

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 we should offer a choice of calculation methods, since the alternatives would all be inferior to the accurate Integration Method that our system uses now. As what is probably the most widely-used source of degree days in the world, we feel it's our responsibility to help worldwide energy data analysis progress in a positive direction with accurate data, rather than helping to perpetuate approximations that just aren't needed any more (given the abundance of detailed temperature data and processing power available nowadays).

Plus we are reluctant to make degree days any more complicated for people than they are already... We don't want people to have to ask "how were these degree days calculated?" each time they deal with data from our system, or analysis based on data from our system.

That said, we are in contact with academics who are researching degree-day-calculation methods – if you are also doing such research, we'd love to hear from you too. And 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.

Specify and Generate Your Degree Days Now