Updating to 5.0.11 from 5.0.10 seems to have fixed the issue as everything now
comes out with Z on the end with both SELECT and CONSTRUCT on both the isql and
/sparql interfaces.
Cheers,
Peter
----- Original Message ----
> From: Peter Ansell <p_ans...@yahoo.com>
> To: Ivan Mikhailov <imikhai...@openlinksw.com>
> Cc: Virtuoso Users List <virtuoso-users@lists.sourceforge.net>
> Sent: Thursday, 9 July, 2009 7:47:44 AM
> Subject: Re: [Virtuoso-users] Date time inconsistency bug
>
>
> Add list to CC...
>
>
> ----- Original Message ----
> > From: Peter Ansell
> > To: Ivan Mikhailov
> > 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
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Virtuoso-users mailing list
> Virtuoso-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
____________________________________________________________________________________
Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
Show me how: http://au.mobile.yahoo.com/mail
