CarlaVS
commented
2 years ago The current documentation suggests using xsd:dateTime. I think because of that specification: "It is not correct to assign the same value to “P82a_begin_of_the_begin” and “P82b_end_of_the_end”. If a value for “P82a_begin_of_the_begin” is given with a precision less than that of xsd:dateTime (i.e. seconds), such as in days or years, the implementation should “round it down” to the first instant of this time expression, e.g. 1971 = Jan 1 1971 0:00:00. Respectively, for “P82b_end_of_the_end” the implementation should “round it up”, e.g. 1971 = Dec 31 1971 23:59:59."
Since we have no indication of time zones in the data. and, after all, the historical time is not exactly congruent with ours (daylight saving time was not introduced until 1980 in Austria), I would suggest the following format: "0001-01-01T00:00:00"^^xsd:date, which is also in the xsd documentation. This format does represent Coordinated Universal Time (UTC), but I don't see a more neutral version.
What do you think?
sennierer
This seems to be a wrong xsd date type: https://github.com/InTaVia/idm-rdf/blob/d8bb7e734b640133f341f54930293031b5a94be5/test_dataset_designsprint/exdataset.ttl#L7100
The correct format is "1845-11-16T00:00:00+01:00", + is for the timeZones. Also we should include the data type: "1845-11-16T00:00:00+01:00"^^xsd:dateTime. We could also think of just using xsd:date "1845-11-16"^^xsd:date