Skip to Main Content
Integration


This is an IBM Automation portal for Integration products. 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 updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.


Status Future consideration
Workspace App Connect
Created by Guest
Created on Apr 1, 2019

ESQL Timestamps loses timezone

When performing a query in the database (Oracle) obtaining data of a column of type "timestamp with timezone", IIB changes the timezone of the date obtained, causing that, when being converted by the system that requested the conversion, at one hour more, change the date.
This issue occurs when you switch to daylight saving time in Brazil.

Idea priority High
RFE ID 131614
RFE URL
RFE Product IBM App Connect Enterprise (formerly IBM Integration Bus)
  • Guest
    Reply
    |
    Sep 25, 2020

    Thank you for taking the time to raise this RFE and apologies we have not been able to prioritize work in this area so far. For the benefit of other readers, the current behaviour of the product has been understood and is described as follows. The IIB ESQL TIMESTAMP structure is passed to the ODBC database driver via an SQL_C_TIMESTAMP structure. This structure is defined by the SQL specification and it does not have any fields to hold timezone information. This means that when the ESQL TIMESTAMP structure is passed to the ODBC driver via the SQL_C_TIMESTAMP structure, the values for 'timezone_hour' and 'timezone_minutes' are lost as there is nowhere to store this information. The SQL_C_TIMESTAMP structure is then passed to Oracle by the ODBC driver. The Oracle TIMESTAMP_WITH_TIMEZONE column is filled in from this structure. However as there is no information about the timezone the 'timezone_hour' and 'timezone_minutes' fields are left as the default. This would then look like a problem when changing to day light savings time as the timezone would then appear to be incorrect for day light savings, for example +00:00 rather than +01:00. However what we are actually seeing is a default timezone of 00:00 being set for both standard time and day light savings time. This problem does not exist if the data is passed to Oracle as a string and then we let Oracle cast it to a timestamp_with_timezone value. In this case the SQL_C_TIMESTAMP structure is not used and so the timezone information is not lost. Status of the RFE is updated to Uncommitted Candidate.

  • Guest
    Reply
    |
    Apr 1, 2019

    Attachment (Description)

  • Guest
    Reply
    |
    Apr 1, 2019

    Attachment (Description)

  • Guest
    Reply
    |
    Apr 1, 2019

    Attachment (Use case)

  • Guest
    Reply
    |
    Apr 1, 2019

    Attachment (Use case)