[Mono-dev] Sybase ASA Odbc, timestamp, fractional seconds, possible bug in mono Odbc stack?

Mads Bondo Dydensborg mbd at dbc.dk
Tue Apr 24 02:36:43 EDT 2007

Hi there

I am using Linux/Mono to access a Sybase ASA server (on Windows), using 
Unixodbc (and possibly FreeTDS - I am actually not quite sure).

Most things appear to work fine, however, when retrieving DateTimes/Timestamps 
from the sybase server, it seems that it returns the fractional value of a 
second, as _billonths_ of a second. Mono appears to expect this in 

ENTER: System.DateTime:.ctor (int,int,int,int,int,int,int)(value:0xbf8b53b0, 
2007, 4
, 17, 14, 10, 50, 340000000, )
. ENTER: System.DateTime:DaysInMonth (int,int)(2007, 4, )
. . ENTER: System.DateTime:IsLeapYear (int)(2007, )
. . LEAVE: System.DateTime:IsLeapYear (int)FALSE
. LEAVE: System.DateTime:DaysInMonth (int,int)result=30
EXCEPTION handling: ArgumentOutOfRangeException

The value 340000000 should be in milliseconds (says DateTime constructor), but 
apperantly is in billionths of a second (nanoseconds, says ODBC).

Looking at OdbcDataReader.GetValue, I find the following code:

case OdbcType.Timestamp:
case OdbcType.DateTime:
case OdbcType.Date:
case OdbcType.Time:
    OdbcTimestamp ts_data = new OdbcTimestamp();
    ret = libodbc.SQLGetData (hstmt, ColIndex, col.SqlCType, ref ts_data, 0, 
ref outsize);
    if (outsize!=-1) // This means SQL_NULL_DATA
      DataValue = new 

OdbcTimestamp.fraction is declared as a long. SQLGetData is an extern method - 
looks like it is just supposed to fill in the binary values? I find it a bit 
puzzling, perhaps even suspiciuos, that ts_data.fraction is converted to an 
int 32 from a long in the call to DateTime - disregarding (perhaps?) the 
scale of the fraction?

I am a bit confused about this. Before looking into it further, I would 
appreciate a comment on wheter this could potentially be a bug in the Mono 
ODBC stack? Also, where values are "set", that is, if wanting to update a 
timestamp from mono - where the conversion takes place (there are quite many 
Odbc related files :-).

The same code runs without problems under Windows/MS. Of course, that is not 
to say it is correct, only that the data returned is as expected.



Med venlig hilsen/Regards

Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg
Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34

More information about the Mono-devel-list mailing list