New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make usage of TIMESTAMP/TIME WITH TIME ZONE convenient for users when appropriate ICU library is not installed on the client side [CORE6286] #6528
Comments
Modified by: @AlexPeshkoffdescription: 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. |
Modified by: @AlexPeshkoffassignee: Alexander Peshkov [ alexpeshkoff ] |
Modified by: @AlexPeshkoffstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 4.0 Beta 2 [ 10888 ] |
Modified by: @dyemanovsummary: 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 |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Resolved [ 5 ] QA Status: No test => Done successfully |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Closed [ 6 ] |
RDB$TIME_ZONE_UTIL package allows to work with TIME ZONE without ICU. This thing was added at year 2018 :) |
Submitted by: @AlexPeshkoff
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.
The text was updated successfully, but these errors were encountered: