Differences between RDF_DATE_TIME and RDF_TIME_DOMAIN

Differences between RDF_DATE_TIME and RDF_TIME_DOMAIN

TNM 283 - Expansion of Date Time Modifier to include additional values

Starting in Q2 2026 (DVN 261E0), the Date Time tables in RDF and FDGB will enhance the Date Time Type to include 25 additional values representing common moving holidays that impact road access and movement. The table below provides a description of the current values and the new values which will be implemented in the Q2 2026 release. HERE will provide the calendar dates for each holiday according to both the Catholic Gregorian and Orthodox Julian calendars. Country release notes will specify which calendar dates are applicable in each country.

Question:

According to the RDF Reference Guide, there are two options in RDF: 'Use either RDF_DATE_TIME or RDF_TIME_DOMAIN for time-dependent conditions.' During the analysis of the 'MovingHoliday' changes, it was observed that RDF_TIME_DOMAIN already contains date definitions for Easter (up to the year 2034), whereas RDF_DATE_TIME (with DATETIME_TYPE='2') does not include any of these definitions. Could you please clarify the reason for this discrepancy?

Answer:

1. RDF_TIME_DOMAIN

This is designed for recurring or rule-based time conditions, such as holidays or seasonal patterns.
It can store predefined date ranges or rules (e.g., Easter, Christmas) for multiple years because these conditions are often reused in routing logic.
That’s why you see Easter dates up to 2034 here—it’s part of a long-term calendar of moving holidays.
RDF_TIME_DOMAIN cannot contain dates like in the new provided LAT.
Can technically only hold one value per condition.
Currently used only for Easter (Catholic Gregorian calendar), and that’s why multiple years of Easter dates are pre-populated.
Customers are advised NOT to use RDF_TIME_DOMAIN for other moving holidays.

E.g. SELECT * FROM RDF_TIME_DOMAIN WHERE feature_id IN (SELECT condition_id FROM RDF_CONDITION_DT rcd WHERE rcd.DT_ID IN (SELECT DT_ID FROM RDF_DATE_TIME rdt WHERE rdt.DATETIME_TYPE = '2'))

[[[(y2025M4d20){d1}]+[(y2026M4d5){d1}]+[(y2027M3d28){d1}]+[(y2028M4d16){d1}]+[(y2029M4d1){d1}]+[(y2030M4d21){d1}]+[(y2031M4d13){d1}]+[(y2032M3d28){d1}]+[(y2033M4d17){d1}]+[(y2034M4d9){d1}]]+[(M12d25){d2}]+[(M12d31){d1}]+[(M1d1){d1}]+[(t1){d1}]]

2. RDF_DATE_TIME (DATETIME_TYPE = '2')

This is for specific, fixed date/time conditions, typically tied to operational restrictions (e.g., road closures, events).
It does not include recurring holidays by default because those are handled by the time domain rules.
If you need Easter in RDF_DATE_TIME, you’d have to explicitly define those dates there—but that’s redundant since RDF_TIME_DOMAIN already covers them.
Is the correct mechanism for all moving holidays.
It uses an additional value (1–26) to indicate the type of moving holiday (e.g., Easter = 11) è TNM
Detailed dates are provided in a separate specification.

E.g. SELECT * FROM rdf.RDF_DATE_TIME rdt WHERE rdt.DATETIME_TYPE = '2'

Conclusion:

the reason for the difference is by design:

RDF_TIME_DOMAIN is a legacy mechanism e.g. Easter only.
* RDF_DATE_TIME is the general solution for all moving holidays.