GRIB time stamps of ERA5 Monthly single levels download

Datasets and Usage C3S - Datasets and Usage
, ,
1

Hi!

I want to download some variable from the dataset: ERA5 monthly averaged data on single levels from 1940 to present. I downloaded it in GRIB format. 

When I inspect the GRIB file using the python package osgeo, the GRIB_REF_TIME and the GRIB_VALID_TIME both give the same slightly off looking time stamp.

To figure out the problem I downloaded two months: January 2021 and Feb 2021. 

Respective time stamps were:

Date EPOCH time stamp Converted to date
Jan 2021 1609437600 2020-12-31 18:00:00
Feb 2021 1612116000 2021-01-31 18:00:00

Does this just mean that the timestamps somehow have shifted 6 hours back in time and I can fix it by adding 6 hours back to it. Or does the 2020-12-31 timestamp correspond to December? I assume the frist one, but I cant find confirmation in the docs. 

When I downloaded data from the Essential Climate Variables, the time stamps corresponded to the first day of the month 00:00. 


Thanks in advance!

Also I'm not a very experienced CDS user and it's my first time using the forum, sorry if question is too simple. 


Code I used:

from osgeo import gdal

grib_file = "ERA5_mo_avg_single_levels_UV_jan_feb_2021.grib"
grib = gdal.Open(grib_file)
band1 = grib.GetRasterBand(1)
band2 = grib.GetRasterBand(2)
print(band1.GetMetadata())
print(band2.GetMetadata())




2

Hi,

What you are seeing is expected behaviour and does not mean that your data correspond to December.

ERA5 monthly means in GRIB format are encoded using the standard ECMWF forecast-style time convention. In this convention, a field is defined by:

an analysis (reference) time (analDate)

a forecast step (endStep or stepRange)

a resulting validity time = analysis time + step

For ERA5 monthly averaged data on single levels, the fields are typically encoded with:

analysis time: 18:00 UTC on the last day of the previous month

step: +6 hours

So for your examples:

2020-12-31 18:00 UTC + 6h = 2021-01-01 00:00 UTC

2021-01-31 18:00 UTC + 6h = 2021-02-01 00:00 UTC

This means:

The timestamp 2020-12-31 18:00:00 corresponds to the January 2021 monthly mean.

The timestamp 2021-01-31 18:00:00 corresponds to the February 2021 monthly mean.

It is therefore not December data, and it is not an error. It reflects the internal GRIB encoding used by ECMWF.

You should not blindly add 6 hours to all timestamps. Instead, if you need the “intuitive” monthly timestamp (e.g. 2021-01-01 00:00), reconstruct the valid time from:

analDate

endStep (or stepRange)

For example (using ecCodes or pygrib), compute:

valid_time = analDate + step (in hours)

This will give you 2021-01-01 00:00:00 and 2021-02-01 00:00:00 respectively.

The Essential Climate Variables datasets often use NetCDF with CF-compliant time coordinates explicitly set to the first day of the month at 00:00, which is why their timestamps look “cleaner”. In GRIB, however, the forecast-style encoding is standard practice.

Your data are correct; the apparent 6-hour shift is just a consequence of the GRIB time convention used for ERA5 monthly means.