description: Time (or timestamp - please keep it in mind here) with TZ is always sent to client using GMT. TZ information may be represented as offset (in that case converting GMT time to local one is not a problem) or zone code, and in this case mentioned conversion is problematic. Client library when can not convert GMT to local time is displaying time in original GMT form. People hate that behavior - they want to be able to get time in a zone as it was entered by default.

In order to solve that problem format extension is suggested - EXTENDED TIME WITH TIME ZONE. That form will have additional 2-byte field where offset of time zone is always placed by DB engine. Conversion of such datatype to local time on client is always trivial. The only place where that datatype may be used is SET BIND statement. To make things a little more flexible a generic 'EXTENDED' pseudo-datatype is also introduced as a target of SET BIND. When it's used (as target) an EXTENDED form of source datatype of SET BIND will be used as target.

And to make it even more flexible 'TIME ZONE' pseudo-datatype should be usable as source type of binding. When it's found in SET BIND that should make such SET BIND match any datatype containing time with time zone.

=>

Time (or timestamp - please keep it in mind here) with TZ is always sent to client using GMT. TZ information may be represented as offset (in that case converting GMT time to local one is not a problem) or zone code, and in this case mentioned conversion is problematic. Client library when can not convert GMT to local time is displaying time in original GMT form. People hate that behavior - they want to be able to get time in a zone as it was entered by default.

In order to solve that problem format extension is suggested - EXTENDED TIME WITH TIME ZONE. That form will have additional 2-byte field where offset of time zone is always placed by DB engine. Conversion of such datatype to local time on client is always trivial. The only place where that datatype may be used is SET BIND statement. To make things a little more flexible a generic 'EXTENDED' pseudo-datatype is also introduced as a target of SET BIND. When it's used (as target) an EXTENDED form of source datatype of SET BIND will be used as target.

And to make it even more flexible 'TIME ZONE' pseudo-datatype should be usable as source type of binding. When it's found in SET BIND that should make such SET BIND match any datatype containing time with time zone.

EXTENDED TIME WITH TIME ZONE should have support by fbclient API in order to perform conversions of that datatype.

assignee: Alexander Peshkov [ alexpeshkoff ]

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 4.0 Beta 2 [ 10888 ]

summary: Use of timestamp or time with TZ is inconvenient for users when appropriate ICU library is not installed on a client => Make usage of TIMESTAMP/TIME WITH TIME ZONE convenient for users when appropriate ICU library is not installed on the client side

status: Resolved [ 5 ] => Resolved [ 5 ]

QA Status: No test => Done successfully

status: Resolved [ 5 ] => Closed [ 6 ]