timrdf/csv2rdf4lod-automation

Use of xsd:date does not output warning/error as suggested by documentation

Closed this issue · 3 comments

https://github.com/timrdf/csv2rdf4lod-automation/wiki/conversion%3Adate_pattern suggests that the following will be emitted if one does not specify a conversion:pattern:

bash-3.2$ ./convert-uk-offshore-oil-wells.sh 
...
DATE FAILED: "1989-10-02" !~ 0 patterns @ :thing_2 :completion_date
...

However, when I did not supply a pattern, the conversion went ahead without errors and the output date was years in the future (e.g. 2013-08-13 became 2180-09-08). I would expect that the behavior should be either as documented or that supplying a valid xsd:date should not change the value of that date (in the absence of conversion:pattern).

Time handling is deferred to Joda time, and a small number of default patterns are provided. Not providing the default patterns would require a user to provide them, at the tradeoff of an incorrect output as you point out here.

Did specifying a pattern correct the output date?

Specifying "yyyy-MM-dd" did correct the problem; I'm just surprised that the format for an XSD date is not one of the default patterns.

On Aug 20, 2013, at 10:56 AM, Tim L notifications@github.com wrote:

Time handling is deferred to Joda time, and a small number of default patterns are provided. Not providing the default patterns would require a user to provide them, at the tradeoff of an incorrect output as you point out here.

Did specifying a pattern correct the output date?


Reply to this email directly or view it on GitHub.

Good catch. The constructors were slightly inconsistent, and the default "yyyy-MM-dd" was only used if you provided some of your own patterns :-). Should be fixed now.