This portal is to open public enhancement requests against products and services offered by the IBM Data & AI organization. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updateson them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,
Post an idea
Upvote ideas that matter most to you
Get feedback from the IBM team to refine your idea
Specific links you will want to bookmark for future use
Row Change Timesatmp with Precision 12 and Timezone
Row change timestamp is sensitive to changing from daylight savings time to standard time since it doesn't support TIMESTAMP WITH TIMEZONE and other precisions than 6. Applications have two requirements that could be combined and solved by the row change timestamp that was introduced in DB2 9 if it was supporting higher precision and storing the timezone.
First, applications need information on when a row was inserted to a table and when the same row was last updated. Having one column defined with TIMESTAMP (12) WITH TIMEZONE WITH DEFAULT will make DB2 insert the wanted information about when the row was inserted. To make DB2 maintain the other column you can use TIMESTAMP (6) WITHOUT TIMEZONE GENERATED ALWAYS FOR EACH ROW ON UPDATE AS ROW CHANGE TIMESTAMP. Since there is no support for TIMESTAMP (12) WITH TIMEZONE for a row change column, there will be a precision discrepancy as well as lack of timezone information in the latter column. Second, applications want to use optimistic locking techniques. The current implementation of row change timestamp is based on storing the local time. This makes the optimistic locking implementation sensitive to the change from daylight savings time to standard time since timestamps might reoccur during the first hour after the change.
Do not place IBM confidential, company confidential, or personal information into any field.