I hope Virtuoso Mars Edition will solve crossplanets timezones
synchronization :)

2010/4/16 Ivan Mikhailov <imikhai...@openlinksw.com>

> Hello Alexander,
>
> I will check details with other developers tomorrow. By default ODBC
> prints strings without timezone offsets and ODBC TIMESTAMP_STRUCT lacks
> timezone offset even in latest versions but I hope that there's some
> method to pass both TIMESTAMP_STRUCT content and the timezone offset.
>
> The server side should deal with tz offsets more accurately. Moreover,
> the server problem is lack of support for timezoneless datetimes --- I'm
> only adding them now but they're not in the production code. Current
> version of Virtuoso keeps all dates/times/datatimes in Oracle style:
> even if a timezone offset is not specified it is set, and the offset
> value is set to server's local offset. That will be changed so
> xsd:dateTime will be able to create values that have no timezone at all,
> as described in http://www.w3.org/TR/timezone/ .
> I should warn that it will make debugging brain-damaging. OTOH it will
> be even worse when we will live on more than one planet --- with
> calendars and timezones out of sync 8:O
>
> Best Regards,
>
> Ivan Mikhailov
> OpenLink Software
> http://virtuoso.openlinksw.com
>
> > Previously I stored DateTime values as strings and casted them to
> > xsd:dateTime dynamically at query time. Then according to Ivan's
> > advice I reimplemented SPARUL part to cast DateTime values when they
> > are added to the store. But now ADO.NET provider returns xsd:dateTime
> > values as strings without timezone offset information. At the same
> > time sparql-endpoint web interface displays values correctly.
> >
> > Regards,
> > Alexander
>
>
>

Reply via email to