A new BUFR sequence for the exchange of daily summary report (DAYCLI)

[sergioh-pessoal]

Introduction

In 2022, the Manual on Codes Volume I.2 (Part B – Binary Codes, WMO-No. 306) introduced BUFR sequence 3 07 075 to support the monthly reporting of daily climate data. This sequence—used for the standardized DAYCLI report—enables WMO Members to share daily climate variable such as temperature and precipitation, including snow, together with their metadata in a harmonized format.

Following expert review and testing, it has been noted that the use of Coordinated Universal Time (UTC) in sequence 3 07 075 may introduce inconsistencies or potential misinterpretations for some National Meteorological and Hydrological Services (NMHSs), particularly those whose climatological observations are structured around their local time zones.

Recognizing that most NMHSs measure, compute, and store daily climatological data according to national or regional time standards, this amendment aims to:

• Avoid error-prone manipulation of dates and times,
• Avoid having datasets with different conventions (national, regional and global),
• Be in accordance with current datasets providers (e.g. NOAA, BoM, Météo-France),
• Support and preserve current national practices;
• Simplify message preparation and post-processing;
• Enhance clarity and reduce the risk of time-based discrepancies.

The amendment is therefore designed to maintain current NMHS practices, to compile messages as easily as possible and at the same time secure and simplify exchanges and post-treatments.

Amendment details

1 – Add new entry in the code table 0 08 025 (time difference qualifier)

Code Figure	Entry Name
0	Universal Time Coordinated (UTC) minus Local Standard Time (LST)
1	Local Standard Time
2	Universal Time Coordinated (UTC) minus Satellite clock
3	Universal Time Coordinate (UTC) minus Reference Date and Time (RDT)	New
4	Reserved
5	Time difference from edge of processing segment
6-14	Reserved

2 - Add new entries in table B for date and time in Reference Date and Time

F-X-Y	Element name	Unit	Scale	Reference Value	Data width (bits)
0-04-044	Year (RDT)	a	0	0	12
0-04-045	Month (RDT)	mon	0	0	4
0-04-046	Day (RDT)	d	0	0	6
0-04-047	Hour (RDT)	h	0	0	5
0-04-048	Minute (RDT)	min	0		0

Note: The descriptors from 0-04-044 to 0-04-048 shall be preceded by the indication of the offset UTC-RDT in minutes.

** 3- Add new entries in table D for date and time in terms of Reference Date and Time **

FXY	Table reference FXY	Element name	Description / comments
3-01-015		Date relative to a referenced date and time (RDT)
	0-04-044	Year (RDT)
	0 04 045	Month (RDT)
	0 04 046	Day (RDT)
3-01-016		Time relative to a referenced date and time and time window
	0-04-047	Hour (RDT)
	0 04 048	Minute(RDT)
	0 04 073	Long time period (days)	Indicate the start of period: set -1 (previous day); set 0 (present day)
	0 04 073	Long time period (days)	Indicate the end of period: set 0 (present day): set 1 (next day)

4 – New BUFR sequence for the exchange of daily summary report (3-07-085)

Differences between this template and the previous one (3-07-075) are in bold.

FXY	Table reference FXY	Element name	Description / comments
3-07-085		Supplemental daily temperature and precipitation values with the time of occurrence for monthly climate report
	3 01 150	(WIGOS identifier)
	3 01 001	Wmo block and station number
	3 01 021	Latitude/longitude (high accuracy)
	0 07 030	Height of station ground above mean sea level (see note 3) (m)
	0 08 095	Siting and measurement quality classification for temperature
	0 08 096	Siting and measurement quality classification for precipitation
	0 08 094	Method used to calculate the average daily temperature	(code table)
	0 08 025	time difference qualifier	Set =3 (UTC-DRT) (New)
	0 26 003	(time difference in minutes)
	3 01 015	Reference Date Year(DRT), Month(DRT), Day(DRT)	(New)
		(Total accumulated precipitation)
	3-01-016	Time relative to a referenced date and time and time window	(New)
	2-04-008	Add associated field	8 bits long
	0-31-021	Associated field significance	Set as 5 for 8-bit indicator of quality control
	0-13-060	Total accumulated precipitation
	2-04-000	Add associated field	cancel
		(Depth of fresh snow)
	3-01-016	Time relative to a referenced date and time and time window	(New)
	2-04-008	Add associated field	8 bits long
	0-31-021	Associated field significance	Set as 5 for 8-bit indicator of quality control
	0-13-012	Depth of fresh snow
	2-04-000	Add associated field	cancel
		(Total snow depth)
	3-01-016	Time relative to a referenced date and time and time window	(New)
	2-04-008	Add associated field	8 bits long
	0-31-021	Associated field significance	Set as 5 for 8-bit indicator of quality control
	0-13-013	Total snow depth
	2-04-000	Add associated field	cancel
		(Max, Min, Mean temperature)
	0-07-032	Height of sensor above local groundfor temperature measurement
	1-07-003	Replicate 7 descriptors 3 times
	3-01-016	Time relative to a referenced date and time and time window	(New)
	0-08-023	First-order statistics	2– maximum; 3 – minimum; 4 – mean
	2-04-008	Add associated field	8 bits long
	0-31-021	Associated field significance	Set as 5 for 8-bit indicator of quality control
	0-12-101	Temperature/air temperature
	2-04-000	Add associated field	cancel
	0-08-083	First-order statistics (code table)	Set as missing value

Requestor(s)

Originator of the initial request

SERCOM / Standing Committee on Climate Services
Expert Team on Data Development and Stewardship (ET-DDS)

INFCOM / Standing Committee on Information Management and Technology****

Stakeholder(s)

No response

Expected impact of change

None

Consultations

SERCOM / Standing Committee on Climate Services
Expert Team on Climate Data Development and Stewardship (ET-DDS)
Expert Team on Monitoring and Communication Climate Variability and Change

INFCOM / Standing Committee on Information Management and Technology
Expert Team on Data Standards (ET-DATA)
Expert Team on Information Management (ET-IM)

Other experts:
Jay Lawrimore, Chief of the Data Set Branch in the Center for Weather and Climate at NOAA's National Centers for Environmental Information

Data exchange plans

This proposed amendment, through the introduction of a new BUFR sequence, is intended to enhance clarity and usability without imposing significant implementation burdens. Notably:
• The new sequence would be made available to all WMO Members;
• Since sequence 3 07 075 is not currently used for DAYCLI exchanges over the Global Telecommunication System or WIS 2, the amendment does not require immediate operational changes;
• The proposed adjustment supports a smoother transition to WIS 2, which will include updated tools (e.g., WIS2BOX) to facilitate adoption and implementation.

Comments

No response

[david-i-berry]

A few of comments/questions:

• This is not really in scope for ET-IM and hasn't been discussed as part of an ET-IM meeting. Some members of ET-IM have commented due to overlapping interests (but outside of ET-IM).
• The information content is the same, whether in local time or UTC, reporting in local time is a convenience for providers and/or end users. Some will keep the data in local time, others will convert to UTC.
• End users need to be consulted, e.g. through GCOS and the regional/global data centres that will use this information. From memory, the request for DAYCLI originally came from GCOS/AOPC.
• How will the date information be stored across multiple time zones, for example in the global data sets?
• What happens when the time zone changes, either due to national legislation adopting a new time zone or through summer time adjustments?

[sergioh-pessoal]

I would like to make a small change to the initial proposal
In the item "add new entry in the code table 0 08 025". Replace "Universal Time Coordinate (UTC) minus Reference Date and Time (RDT)" to "Reference Date and Time (RDT) minus Universal Time Coordinate (UTC)" .
This modification is necessary to the time difference (0 26 003) is coded according time zone convention, i.e. positive to the East and negative to the West,

[DenisStuber]

Attempt to answer Dave's questions:
The information content is the same, whether in local time or UTC, reporting in local time is a convenience for providers and/or end users. Some will keep the data in local time, others will convert to UTC.

The NMHss will report DAYCLI according their own practices which are not necessary in UTC.
Global daily data provider such as NCEI, and national providers such as BoM and Météo-France are already collecting and sharing daily data in Reference Date and Time.
End users of the DAYCLI should decide whether to use “Reference Date and Time” as it is, or to change to another convention if necessary and possible.

End users need to be consulted, e.g. through GCOS and the regional/global data centres that will use this information. From memory, the request for DAYCLI originally came from GCOS/AOPC.

Yes, that is indeed important.
The current modifications (Reference Date and Time) already came from WMO members. This should be widely validated by other members. Tests are strongly recommended.
The question remains about which regional/global centers will collect DAYCLI messages?
As the BUFR sequence of the DAYCLI message (3 07 075) is not used yet by NMHSs it is important to modify the BUFR sequence, if needed, in the very short term.

How will the date information be stored across multiple time zones, for example in the global data sets?

Daily data will be stored in Reference Date and Time (RDT) for each station, that is the date used by the data owner/provider. This will insure the time series integrity.
The offset against UTC for each station will also be present.

What happens when the time zone changes, either due to national legislation adopting a new time zone or through summer time adjustments?
This question is crucial.
The definition of the Reference Date and Time (RDT) is not equal to the standard time zones. Standard time zones are for legal, commercial and social purposes (See [](Wikipedia https://en.wikipedia.org/wiki/Time_zone)).
RDT is used at the station level to assigned the observations to a special date and time. RDT could be equal to UTC but also to many other cases. RDT is not supposed to change even if standard time zone is modified (e.g. adoption of a new time zone by a country). As well, considering WMO recommendations, RDT is not supposed to change for summer time adjustments (Daylight Saving Time DST).
In spite of everything, if a time reference changes for a station (which would be very rare!), this must be indicated by the “Time difference in minute” parameter (0 26 003) in the BUFR sequence.
As regard Daylight Saving Time (DST), it is true that some climatological stations are using DST for surface observations.
According the BoM, in the past and in Australia, it exists areas were some surface observations were made according DST. In Australia, it seems that DST has been started to be used in 1973. See .
The changeover dates for DST are not identical year after year for the same station, and they differ from one zone/country to another. A station may also observe DST time for a period and then revert to do not observe DST.
Due to the fact that:
• DST is not recommended by WMO;
• Today very (very!) few stations follow DST;
• Managing DST will be complex and costly in term of human resource (implementation, training, etc.);
• It will give a negligible gain in terms of climatic signal;
The suggestion is then to consider that all stations into the DAYCLI message do not modify their time of observation during the year with daylight saving time (DST). So, no change, except to write this consideration into the handbook.
On the other hand, outside the issue of the DAYCLI, NMHSs should be encouraged to fill in all the metadata linked to the observation, particularly the DST switches, especially for historical data. By way of example see the global IANA Time Zone Database (See https://www.iana.org/time-zones).

[DenisStuber]

Link to the presentation explaining the modifications for the DAYCLI : https://github.com/ET-DRC/DAYCLI-message/blob/main/Meetings/20250527_V2-%20DAYCLI%20Amendment.pdf

[david-i-berry]

The definition of the Reference Date and Time (RDT) is not equal to the standard time zones.

I think this is a key piece of information but that is not clear from the proposal.

Say I have a maximum temperature observed over the period 2025-05-26T08:00+5/2025-05-27T08:00+5 (local time, UTC+5) this would correspond to 2025-05-26T03:00+0/2025-05-27T03:00+0 (UTC). In this case what should the reference time be and how is the difference from UTC calculated?

At the moment 2025-05-26T03:00+0/2025-05-27T03:00+0 is reported in the existing BUFR sequence. In the new proposal what would be reported and how is it made clear that the RDT is not local time?

[DenisStuber]

As far as I understand, here is missing the parameter that we want to add to the BUFR sequence. That means the offset between the RDT and UTC that gives the day from which are attributed the maximum of temperature.
Having just the time period of the maximum temperature does not give us the RDT of the station.
We could exchange later on better about this case...

[amilan17]

https://github.com/wmo-im/et-data/wiki/2025.05.27.et.data notes:
Sergio presented the proposal, invited Denis Stuber to present the ppt (above) and the team discussed the proposal and the team discussed it;

some discussion notes.... [@wmo-im/et-data please add clarifications in comments below if not captured correctly here]

• Is RDT well understood in the community? It may need a definition

• It may not be necessary to add 5 new descriptors

  • significance qualifier (e.g. 0-08-025 or 0-08-021) can already be used with 004001 through 0004005 descriptors to report times or time periods other than just UTC observation times
  • there is already a descriptor for local time (LT) and a way to describe the difference from UTC (see 0-04-041), so instead could we just add a similar descriptor for RDT-UTC? - previous efforts for describing time differences from UTC did not require a new set of time descriptors

• with current DAYCLI, there is a way to calculate the time

• use a different name then reference date, perhaps climatological date?

• at a minimum UTC offset is needed

• try to target for FT2025-2

• @amilan17 coordinate ad-hoc meetings with @sergioh-pessoal @jbathegit @SibylleK @marijanacrepulja

[uripharyoko]

Hi Denis,
BMKG (Indonesia Agency for Met Clim and Geo), now is trying to create DAYCLI data in BUFR format. I supervised some stafs to prepare from the beginning (from extracting the data from CDMS until creating the BUFR format data). However, I don not have capabilities to verify whether the data format is correct or not. Please give your suggestion, to whome shoud I send the data to check.

Thank

[ET-DRC]

The definition of the Reference Date and Time (RDT) is not equal to the standard time zones.

I think this is a key piece of information but that is not clear from the proposal.

Say I have a maximum temperature observed over the period 2025-05-26T08:00+5/2025-05-27T08:00+5 (local time, UTC+5) this would correspond to 2025-05-26T03:00+0/2025-05-27T03:00+0 (UTC). In this case what should the reference time be and how is the difference from UTC calculated?

At the moment 2025-05-26T03:00+0/2025-05-27T03:00+0 is reported in the existing BUFR sequence. In the new proposal what would be reported and how is it made clear that the RDT is not local time?

In this case, I suppose here that UTC +5 = local time = Reference Date and Time
With the BUFR sequence 3 07 075 all in UTC
3 01 011 Year Month Day: 2025-05-25 (If you are at UTC+5 the date 2025-05-26 00:00 becomes 2025-05-25)
0 04 023 Time Period Displacement: +1 (day +1 for TMax)
3 01 013 Hour, minute, second: 03:00:00 (beginning of the observation of TMax)

With he proposed BUFR sequence with Reference Date and Time replacing UTC
3 01 015 Year Month Day: 2025-05-26 (As given by the NMHS)
0 26 003 Time difference in minute: 300 (5*60 minutes UTC+5)
0 04 023 Time Period Displacement: 0 (same day for Tmax)
3 01 013 Hour, minute, second: 08:00:00 (beginning of the observation of TMax)