Proposal: `tree:defaultTimezone` for non time zoned `xsd:dateTime` literals

[pietercolpaert]

Problem

The raw data that someone wants to publish in a tree:Collection uses xsd:dateTime literals without timezone, as the data is only about a specific country that will always be in the same timezone. At this moment, the data provider must add a timezone to all these literals when publishing the data. However, the issue could also be solved by setting a default timezone for the tree:Collection.

Proposed solution

Introduce a property tree:defaultTimezone:

• Domain: tree:Collection
• Range: xsd:string -- that follows the timezone indicator of the xsd:dateTime. I.e.: a range [-14:00,+14:00] or Z. E.g., Z, +01:00, -10:00 ...

A tree:defaultTimezone MUST appear in the metadata in the first tree:Node (root node) that the client will encounter. When set, the timezone indicator will be added to xsd:dateTime.

This will also add an option in the text of the main spec on how to compare time literals, that when no timezone is known for the tree:value, it should use the default timezone documented in the root of the search tree.

Discussion

I am not a fan of this proposal myself but wanted to have this issue documented and discussed in the TREE CG:

• This proposal would add more complexity when comparing time literals, while we probably want to prioritize the simplicity to implement a client. I think the effort for a server provider to add the timezone explicitly in the literals is minor.
• Question is what the client needs to do: would the client, when fetching the triples actually change the xsd:dateTime literals to now include a timezone? That way, technically a derived version of the collection would be produced.