Time

How Qumasc names periods, forms monthly and daily values, treats accumulated variables, computes degree days and represents fixed values without a period. (Updated 6 October 2026)

Summary. Every value of a Qumasc table belongs to a period named by its first day and its length. Monthly values follow the conventions of the providers; daily values are UTC days unless a fixed offset is requested; accumulated variables are de-accumulated by an explicit rule; degree days are computed per day and grid cell with the thresholds of Eurostat and the JRC. Indicators of layers without dates are fixed values with the period P0D, which a combined table repeats in every period.

Periods

A period is stored as period_start (a date) and period, an ISO 8601 duration: P1D for a day, P1M for a month, P1Y for a year. In the previews and the API the two are joined as an interval, for example 2024-01-01/P1M. Rows of different lengths may stand side by side in one table; nothing is interpolated between them.

Monthly values

The Climate Data Store labels each month with its first day at 00 UTC. Monthly means of temperature, dewpoint, soil moisture and wind speed are means over the month. Precipitation in the ERA5-Land monthly means is the mean daily accumulation in metres per day, so the monthly total in millimetres is the value times the days of the month times 1000; validation fails if an accumulated variable of that product is aggregated without this scaling. Wind speed is computed from the hourly wind components before averaging, because the magnitude of mean components underestimates the mean speed whenever the direction varies.

Annual values are formed from the months: temperature, dewpoint, wind speed and soil moisture as means weighted by the days of each month, precipitation as a sum. By default only complete years receive a value.

Recent months that are still preliminary in the source are included and flagged preliminary; running the recipe again later gives the consolidated values.

Daily values and the UTC day

The daily workflows read hourly ERA5-Land and reduce it to days per grid cell, and only then aggregate to regions. Everything that involves a minimum, a maximum or a threshold is computed per cell at the native resolution first; a threshold is never applied to a regional or monthly mean.

Days are UTC days by default. A fixed offset in whole hours from UTC can be requested; for Poland an offset of one hour gives the days of Central European Time all year. Local days with daylight saving time are not offered: they would have days of 23 and 25 hours, and no reference product uses them. The day definition is stored with the time coordinate and in the provenance, stated as a warning when the recipe is validated, and explained in a note on the data. Local time in Poland is one to two hours ahead of UTC and the stations use another climatological day, so single daily values are not comparable one to one with station records.

Accumulated variables

Hourly ERA5-Land precipitation is accumulated since 00 UTC: the value at 00 UTC is the total of the previous day, and the daily total of day D is the value at 00 UTC of day D+1. The rule is declared in the recipe (accumulation: era5_daily_from_00utc), the source reads one hour beyond the period, and only the sum is allowed as a reduction for such variables. Validation refuses accumulations reduced without the rule and sources that lack the hours the day boundaries need.

On the first run with real data the monthly sums of the daily totals equalled the monthly totals of the monthly-means product to 0.03 % for every region and month.

Degree days

Heating and cooling degree days follow the definition used by Eurostat and the JRC:

heating degree days: 18 °C minus Tm on every day with Tm at or below 15 °C, otherwise 0;
cooling degree days: Tm minus 21 °C on every day with Tm at or above 24 °C, otherwise 0.

Tm is, by default, the mean of the 24 hourly values of the day. The variant (minimum + maximum) / 2, the definition of the JRC gridded agro-meteorological data, is available as an option; on the first run neither was clearly closer to the Eurostat values. Other base temperatures and thresholds can be given as parameters. Degree days are computed per day and grid cell, then summed to months and years together with the number of valid days; incomplete months and years have no sum. The operation is refused on monthly means, from which degree days cannot be derived exactly. Counts of days that pass a threshold (frost days, summer days, tropical nights and others) are formed in the same way.

How the results compare with the Eurostat degree days is described under Validation.

Incomplete periods

When the steps with a value do not cover a period completely, the period is flagged incomplete_period. On a value, the flag says that the value rests on part of the period; on an empty value, that too few steps had a value. By default only complete periods receive a value.

Fixed values without a period

Some indicators are not time series. A layer of a government vector service (the protected areas of a region, for example) has no dates: it describes the state on the day it was retrieved. Its indicators are fixed values with the period P0D, a period of length zero, starting on that day, which is also kept in the column reference_date.

When a combined table joins such a component with time series, the fixed value is joined on the region only and repeated in every period of the table, every month and every year that the other components have. Each such component receives a note on the data, for example "fixed value, not a time series; valid as of 2026-10-03; repeated in every period", and the merge report lists it. A table without any time series keeps the fixed values once with their period P0D; no periods are invented. Fixed values cannot be aggregated over time.

Indicators of an OpenStreetMap extract are treated as an annual component: their rows carry the year of the extract and the day of the extract in reference_date.

Periods in combined tables

A combined table keeps the period of every row: monthly and annual rows stand side by side. Rows of finer periods (daily values, dekads) are left out and counted, and an input known to be finer than months is refused when the recipe is validated; such inputs are reduced to months or years first.