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 > > >