On 3/4/19 12:53 PM, Mark Rotteveel wrote:
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, I'm not 100% sure for TZ id but in all other known to me cases
16-bit integers are sent over the wire in 32-bit network format. I
suppose you should read that id as any other 16-bit value.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
