Add list to CC...
----- Original Message ----
> From: Peter Ansell <p_ans...@yahoo.com>
> To: Ivan Mikhailov <imikhai...@openlinksw.com>
> Sent: Thursday, 9 July, 2009 7:46:13 AM
> Subject: Re: [Virtuoso-users] Date time inconsistency bug
>
> Hi Ivan,
>
> I am using a slightly old version of virtuoso open source, but I am doing
> things
> slightly differently to you... I was under the impression the correct way to
> represent date time values in NTriples was using the ^^xsd:dateTime
> convention
> to make the date time value into a typed literal. Is that what is causing the
> error? Are date time values valid URI's?
>
> I will update to the current 5.11 version and see if the bug still exists.
>
> Connected to OpenLink Virtuoso
> Driver: 05.10.3037 OpenLink Virtuoso ODBC Driver
> OpenLink Interactive SQL (Virtuoso), version 0.9849b.
> Type HELP; for help and EXIT; to exit.
> SQL> sparql insert in graph
> {
> "2009-07-08T00:50:36Z"^^xsd:dateTime };
> callret-0
> VARCHAR
> _______________________________________________________________________________
>
> Insert into , 1 triples -- done
>
> 1 Rows. -- 53 msec.
> SQL> sparql select * where { graph{ ?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-08 00:50:36
>
> 1 Rows. -- 1 msec.
> SQL> sparql construct { ?s ?p ?o . } where { graph{ ?s ?p
> ?o . } };
> callret-0
> LONG VARCHAR
> _______________________________________________________________________________
>
> @prefix xsd: .
> @prefix dc: .
> @prefix ns2: .
> ns2:i dc:date "2009-07-08T00:50:36.000+10:00"^^xsd:dateTime .
>
> 1 Rows. -- 2 msec.
>
> As you can see the bug with the +10:00 (which is the timezone on the server),
> exists.
>
> It is interesting how the output from queries on /sparql is slightly
> different
> again though, as the output for select queries on /sparql adds .000 to the
> end
> of the xsd:dateTime like string, but doesn't put Z on the end or any timezone.
>
>
>
> Thanks,
>
> Peter
>
>
> ----- Original Message ----
> > From: Ivan Mikhailov
> > To: Peter Ansell
> > Cc: Virtuoso Users List
> > Sent: Thursday, 9 July, 2009 4:59:17 AM
> > Subject: Re: [Virtuoso-users] Date time inconsistency bug
> >
> > 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
> > {
> > <2009-07-08T00:50:36Z> };
> > callret-0
> > VARCHAR
> >
> _______________________________________________________________________________
> >
> > Insert into , 1 triples -- done
> >
> > 1 Rows. -- 6 msec.
> > SQL> sparql select * from 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 where
> > {?s ?p ?o};
> > callret-0
> > LONG VARCHAR
> >
> _______________________________________________________________________________
> >
> > @prefix dc: .
> > @prefix ns1: .
> > 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
>
>
>
>
> ____________________________________________________________________________________
> Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
> Show me how: http://au.mobile.yahoo..com/mail
Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
Show me how: http://au.mobile.yahoo.com/mail
