Skip to content
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

Closed
firebird-issue-importer opened this issue Apr 20, 2020 · 6 comments

Comments

@firebird-issue-importer

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.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Apr 20, 2020

Modified by: @AlexPeshkoff

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.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Apr 20, 2020

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Apr 20, 2020

Modified by: @AlexPeshkoff

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

resolution: Fixed [ 1 ]

Fix Version: 4.0 Beta 2 [ 10888 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Apr 21, 2020

Modified by: @dyemanov

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

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Apr 22, 2020

Modified by: @pavel-zotov

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

QA Status: No test => Done successfully

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Apr 22, 2020

Modified by: @pavel-zotov

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants