Differences between RDF_DATE_TIME and RDF_TIME_DOMAIN

Applies To
----------

HERE RDF Data Deliveries
RDF Reference Guide implementations
FDGB
HERE Platform map data consumers

Symptoms / Triggers
-------------------

Customers may report one or more of the following:

Easter dates appear in RDF_TIME_DOMAIN but are not visible in RDF_DATE_TIME.
Validation queries show different results between RDF_TIME_DOMAIN and RDF_DATE_TIME.
* Moving holiday conditions appear incomplete when reviewing RDF_DATE_TIME records.
* Holiday-related road restriction analysis returns different results depending on the table queried.
* During TNM 283 validation, holiday records appear inconsistent across RDF datasets.

Summary:
--------

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.

Keywords or Tags:
-----------------

* Easter
* RDF_DATE_TIME
* RDF_TIME_DOMAIN
* TNM 283
* missing holiday dates
* routing restriction
* DATETIME_TYPE
* RDF validation
* road restrictions
* time dependent conditions
* FDGB
* recurring holidays