Working with temporal data on the Semantic Web remains challenging due to SPARQL's limited support for comparing time literals of different data types and handling floating times without explicit time zones. These issues are especially problematic when dealing with partial time literals (such as xsd:date, xsd:gYearMonth, or xsd:gYear) and floating times, both of which are common in real-world knowledge graphs like Wikidata. To showcase the relevance and urgency of the problem, we gathered and reviewed existing discussions, specifications, draft proposals, and examples from deployed knowledge graphs, providing a consolidated starting point for further community dialogue. We then proposed a solution in the form of a set of SPARQL extension functions-Time Functions-designed to reinterpret time literals as time intervals, enabling consistent and type-agnostic temporal comparisons. These functions are formally described using the Function Ontology (FnO), and implemented in the Comunica query engine, with a publicly available demo application that allows users to interactively explore and test the functions. The demo includes curated example queries that highlight both the limitations of existing SPARQL behavior and how the Time Functions enable more accurate filtering and sorting of temporal data. In addition to providing a technical proposal, we advocate for improved temporal data publishing practices, urging data providers to use accurate data types and explicit time zones to support reliable temporal reasoning in the openworld context of RDF.
and querying frameworks such as Virtuoso, BlazeGraph, and Comunica return false or empty results in these cases, even if the date parts of the literals are comparable.
This issue becomes problematic in large-scale, real-world knowledge graphs like Wikidata, where users can specify date precision (e.g., year, month, day) when entering temporal data. Its SPARQL end‐ point, however, returns fully qualified xsd:dateTime values without indicating the original precision. For example, a historical event entered as 27th century BCE may appear as such in the user interface, but is internally represented and queryable only as "−2650-01-01T00:00:00Z"^^xsd:dateTime. This loss of preci‐ sion in the queryable data undermines temporal reasoning and can produce misleading query results, such as asserting that this historical event happened in the month of January.
Another critical challenge arises with floating times, which are time literals that lack time zone infor‐
mation. A literal like "2025-08-01T12:00:00"^^xsd:dateTime can be interpreted differently depending on
the context, or may be wrongly adjusted to the user’s local time zone. This ambiguity makes consistent
comparison and sorting unreliable. While the W3C Group Draft Note on Working with Time and
Timezones [
A more robust approach is to treat all temporal literals—particularly floating and partial ones—as
time intervals, bounded by their earliest and latest possible interpretations. For example, a floating
time can be represented by the time interval it could occupy across the full range of legal time zone
offsets (−14:00 to +14:00, as per XML Schema Part 2: Datatypes Second Edition [
Despite the growing interest in temporal reasoning on knowledge graphs, e.g., in works such as
Soulard et al. 2025 [
This paper aims to highlight these overlooked issues and present a concrete, extensible solution. We propose a set of SPARQL extension functions—called Time Functions—that enable comparison across different temporal data types, interpretation of floating and partial times as intervals, and consistent and explainable time-based filtering and sorting.
The remainder of this paper is structured as follows. Section 2 introduces the proposed SPARQL ex‐ tension functions for time handling, along with their formal semantics. Subsequently, Section 3 presents a demo application showcasing how these functions enable richer and more accurate tempo‐ ral queries over RDF data. Finally, Section 4 concludes with a discussion of how Time Functions ad‐ dress the limitations of SPARQL for temporal reasoning, highlights their relevance for future standard‐ ization, and encourages improved temporal data publishing practices.
To address the limitations of SPARQL when dealing with temporal data, particularly the inability to compare partial or floating time literals, we propose a set of SPARQL extension functions called Time Functions. These functions allow for consistent, meaningful comparison and reasoning over heteroge‐ neous temporal literals by interpreting them as time intervals.
The formal specification and accompanying ontology for these functions are available at https://
w3id.org/time-fn. The ontology uses the namespace https://w3id.org/time-fn# with the recommended
prefix tfn:. This specification defines the semantics of each function and provides an ontology for inte‐
grating time-aware logic into SPARQL queries. The ontology relies on the Function Ontology (FnO) [
Time Functions treats all temporal literals as time intervals, interpreted as the range of time they
could represent based on their earliest and latest possible interpretations. For instance, a literal
"2025-08"^^xsd:gYearMonth spans from August 1st ("2025-08-01T00:00:00-14:00"^^xsd:dateTime) to August
31st ("2025-08-31T23:59:59+14:00"^^xsd:dateTime). As discussed in Section 1, the W3C XML Schema
Recommendation [
By shifting from point-based to interval-based reasoning, these functions enable meaningful com‐ parisons across data types, handle ambiguities introduced by missing time zones or precision, and make temporal filtering in SPARQL more reliable and consistent.
The current Time Functions include five core functions:
• tfn:periodMinInclusive(?timeLiteral): Returns the inclusive lower bound of the time period repre‐
sented by the given temporal literal, as an xsd:dateTime. For example, for "2025-08"^^xsd:gYearMonth,
it returns "2025-08-01T00:00:00.000+14:00"^^xsd:dateTime.
• tfn:periodMaxInclusive(?timeLiteral): Returns the inclusive upper bound of the time period rep‐
resented by the given temporal literal. For the same example, it returns
"2025-08-31T23:59:59.999-14:00"^^xsd:dateTime.
• tfn:periodMinExclusive(?timeLiteral): Returns the exclusive lower bound of the time period. This
is particularly useful for defining open-ended or non-overlapping intervals in filtering logic. For the
same example, it returns "2025-07-31T23:59:59.999+14:00"^^xsd:dateTime.
• tfn:periodMaxExclusive(?timeLiteral): Returns the exclusive upper bound of the time period. For
the same example, it returns "2025-09-01T00:00:00.000-14:00"^^xsd:dateTime.
• tfn:bindDefaultTimezone(?timeLiteral, ?timeZone): For a given floating time literal, this func‐
tion returns a new literal of the same type with the specified time zone bound. If the literal already
includes a time zone, no default time zone needs to be bound to it, and it is returned unchanged. For
the same example, it returns "2025-08+02:00"^^xsd:gYearMonth when bound to the +02:00 time zone.
The function aligns with the approach proposed in Working with Time and Timezones [
The Time Functions are applicable in a wide range of practical scenarios. When comparing dates of different data types, such as matching an xsd:dateTime with an xsd:date, the functions allow both val‐ ues to be interpreted as intervals and compared accordingly. This is particularly useful in knowledge graphs where schema constraints are loose and data often lacks uniform temporal granularity.
Floating time literals pose challenges in distributed and heterogeneous datasets. Without a defined time zone, their interpretation is ambiguous, leading to incorrect comparisons or missed matches. Time Functions make it possible to consistently bind a default time zone where appropriate or interpret the literal as an interval that spans all possible time zones, depending on the application’s needs.
These functions also support more advanced temporal logic, such as detecting overlaps between time periods, validating temporal boundaries, and improving sorting behavior. In knowledge graphs like Wikidata, where date precision is user-defined but not preserved in SPARQL query results, Time Functions allow users to reconstruct and reason about the intended temporal scope of such data. More generally, they provide a principled foundation for integrating diverse temporal representations in SPARQL queries, enabling more accurate and expressive querying of temporal knowledge. 3. Demo
To illustrate the practical utility of the Time Functions, we developed an online demo application, available at https://smessie.github.io/TimeFunctions-SPARQL-Editor/. The application is a lightweight SPARQL query editor that allows users to experiment interactively with the Time Functions described in Section 2.
Users can write and execute SPARQL queries, demonstrating how the Time Functions can address
limitations in standard SPARQL when comparing partial or floating time literals. Under the hood, the
demo runs on the Comunica query engine [
The application includes example queries that highlight common pitfalls when working with time literals in SPARQL, as well as how the Time Functions can be used to resolve them. Fig. 1 shows a screenshot of the demo with a query that compares an xsd:date to an xsd:dateTime. Since SPARQL does not support comparisons between these types, the query yields no results—even though the date com‐ ponents are logically comparable. In Fig. 2, the same query is rewritten using the Time Functions to map both literals to their corresponding time intervals. This allows for a meaningful comparison, and the query returns the expected result.
In this paper, we have highlighted an important gap in the current processing of SPARQL queries dealing with temporal data. This gap includes the inability to directly compare logically comparable data types such as xsd:date and xsd:dateTime, as well as potential ambiguity when dealing with floating time literals, especially in federated or heterogeneous data settings. Moreover, current data modeling practices further complicate temporal reasoning: for instance, Wikidata represents imprecise time peri‐ ods such as “27th century BCE” using a single xsd:dateTime literal (e.g., “-2650-01-01T00:00:00Z”), thereby flattening a broad time range into a misleading instant. These challenges highlight a broader need for improved temporal data publishing practices: data should be expressed using accurate data types that reflect temporal granularity, and time zones should be made explicit wherever possible to avoid implicit and potentially conflicting assumptions.
To address these limitations, we proposed a set of SPARQL extension functions, Time Functions, which reinterpret time literals as time intervals, enabling consistent and type-agnostic comparisons. These functions support partial dates, floating times, and even cross-type comparisons by interpreting each time literal as a bounded interval, which can then be compared meaningfully using SPARQL. Additionally, a function for binding a default time zone enables explicit handling of floating times in a configurable way. These functions are formally specified using FnO, following established practices such as those in GeoSPARQL, and are implemented in a demo application using the Comunica query engine. Our demonstrator provides an interactive environment to explore the functions in action and illustrates how they resolve common pitfalls in temporal querying.
While the functions offer an immediate and practical solution, they are also intended to contribute to the broader discussion around improving temporal reasoning in the upcoming SPARQL 1.2 and be‐ yond. By surfacing the challenges and demonstrating a viable path forward, we hope this work sparks further standardization efforts and community feedback.
3. https://github.com/opengeospatial/ogc-geosparql/blob/master/vocabularies/functions.ttl ↩ 4. https://github.com/smessie/TimeFunctions-SPARQL-Editor/blob/main/src/assets/queryWorker.ts ↩
During the preparation of this work, the author(s) used ChatGPT, DeepL in order to: Grammar and spelling check, Paraphrase and reword. After using this tool/service, the author(s) reviewed and edited the content as needed and take(s) full responsibility for the publication’s content.