This portal is to open public enhancement requests against IBM Z Software 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).
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:
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 an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
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.
See this idea on ideas.ibm.com
We would like to have the following three UTC plus an addition local time date pattern supported by the DATETIME and REPATTERN built-in functions:
1) 'YYYY-MM-DDTHH:MI:SS.999S99:99'
2) 'YYYY-MM-DDTHH:MI:SS.999Z'
3) 'YYYY-MM-DDTHH:MI:SS.999 UTC'
4) 'YYYY-MM-DDTHH:MI:SS.999' (local time)
1) would be understood to hold a UTC-plus-offset or extended-UTC value.
2) and 3) would be understood to hold a UTC value.
4) is the equivalent pattern in local time.
REPATTERN will have to support the converting between UTC and local time as follows:
UTC date pattern as source:
- When converting from an extended-UTC date to something other than a UTC date, the offset value will be added to the hours and minutes part (as I think you wanted in your note below)
- When converting from an extended-UTC date to a UTC date, the offset value will be ignored if the target is not an extended-UTC date (otherwise it will be copied)
- When converting any other UTC date to an extended-UTC date, the offset value will be set to +00:00
- When converting any other UTC date to any other date, there will be no attempt to adjust for the local time: the date/time parts will simply be adjusted as needed
UTC date pattern as target:
- When converting to an extended UTC format, the offset value will be set to +00:00 unless the source is also an extended UTC date
- When converting to any other UTF format, there will be no attempt to adjust for the local time: the date/time parts will simply be adjusted as needed
- So, for both of these scenarios, the user is responsible for insuring that the source holds a UTC value - as would be true if the source were obtained from the UTCDateTime function
Idea priority | Low |
By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.
This requirement has been re-assessed. It is not likely that this will be implemented in the next 12-24 months and so it is being declined at this point. The requirement will be kept in the RFE system and might be reassessed in the future. If you still want this, please submit a new RFE for it
the formats other than the UTC ones were delivered earlier this year. We hope to work on some UTC format support soon.
I would like, that PL/I supports at least the dateformats that DB2 has already.
It is better (more performant) to convert timestamps in pl/i rather than in DB2.
This could be very useful to have