Hello Peter, I'm sorry I can't reproduce the bug without exact script of your attempt. If I try
SQL> sparql insert in graph <http://mygraph.com> { <http://www.dajobe.org/foaf.rdf#i> <http://purl.org/dc/elements/1.1/date> <2009-07-08T00:50:36Z> }; callret-0 VARCHAR _______________________________________________________________________________ Insert into <http://mygraph.com>, 1 triples -- done 1 Rows. -- 6 msec. SQL> sparql select * from <http://mygraph.com> where {?s ?p ?o}; s p o VARCHAR VARCHAR VARCHAR _______________________________________________________________________________ http://www.dajobe.org/foaf.rdf#i http://purl.org/dc/elements/1.1/date 2009-07-08T00:50:36Z 1 Rows. -- 11 msec. SQL> sparql construct { ?s ?p ?o } from <http://mygraph.com> where {?s ?p ?o}; callret-0 LONG VARCHAR _______________________________________________________________________________ @prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix ns1: <http://www.dajobe.org/foaf.rdf#> . ns1:i dc:date <2009-07-08T00:50:36Z> . 1 Rows. -- 3 msec. SQL> then you may see that it prints both time and 'Z' accurately. Note, however, that default SQL format for datetime lacks timezone notation. When SQL was developed, the client and the server were (almost) always in same timezone. Now the world is connected much better and the spec is simply obsolete. So when a conversion delivers only "2009-07-08T00:50:36" and not "Z" then it's probably intentional "weird" cast to string, not a bug. Best Regards, Ivan Mikhailov OpenLink Software http://virtuoso.openlinksw.com On Tue, 2009-07-07 at 18:00 -0700, Peter Ansell wrote: > Hi all, > > I am trying to figure out why when I insert xsd:dateTime typed literals in > the form "2009-07-08T00:50:36Z", they come out of SELECT sparql queries as > "2009-07-08T00:50:36.000" and they come out in CONSTRUCT sparql queries as > "2009-07-08T00:50:36.000+10:00". I think for select queries everything is > working, but I don't know why there is an arbitrary 10:00 added to the end of > the value, especially since the time value isn't changed, and if interpreted > literally I could imagine it being interpreted as "2009-07-07T14:50:36Z" if > you thought you needed to take 10 hours off to get to the Z time offset. > Simply put, it is a bug somewhere at minimum that SELECT queries aren't > consistent with CONSTRUCT queries. > > Is there anywhere that this can be configured so that it keeps putting > dateTime out using the "2009-07-08T00:50:36Z" style instead of either of the > other two styles and then the results from SELECT and CONSTRUCT can both be > used with the same style that I am using in the RDF I am inserting. > > Cheers, > > Peter
