I noticed when using native connections when experimenting with time
zone support in Jaybird, that the buffer returned by the client for a
TIMESTAMP WITH TIME ZONE will be 12 bytes, even though it is a TIMESTAMP
(8 bytes) + short (2 bytes) for the id (possibly due to padding).
For the network protocol the use of 12 bytes is expected, as there 16
bit shorts are encoded as 32 bit integers. And when processing this
little endian there is no real problem (using 2 bytes or 4 bytes in
little endian should yield the same value assuming that if it is padded,
the padding is all zeroes).
As I don't have access to a big endian system, I am wondering how I
should read the buffer, because for big endian systems, reading only
bytes 9 and 10, or reading bytes 9-12 will yield significantly different
values.
So the question is, when reading the buffer from a native client, should
I just read 2 bytes and ignore the remaining 2 bytes as padding, or
should I read all 4 bytes?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
