On 4-3-2019 10:53, 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?
Interesting bit of information: in the wire protocol, the time zone id
is encoded as a signed short, which results in for example Europe/Moscow
(id = 65064 or 0xFE28) being encoded as bytes 0xFFFFFE28 due to
sign-extension, in little-endian native, the buffer has 0x28FE0000. This
suggests that native only uses two bytes plus two padding bytes.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
