Hi again
As for the character representation - when on the i you use an ISO
format like this -
2015-10-16-15.04.30.000000
in the case of your example - at least, IBM calls this ISO.
But your example includes the time zone offset, right?
Drivers for JDBC and ODBC and OLEDB providers can handle the formats you
describe, I believe.
I admit to being curious - what are the problems you are trying to solve?
As to saying the external representation is ISO, that is interesting - I
looked at something on ISO8601 and see that the T is optional, although
it probably means a space would replace it. IBM's form has a hyphen
there. And the separator for the time is a period on the i, not a colon
as 8601 has it, with no provision for the use of the period.
RFC3339 has this "interesting" statement about the T:
NOTE: ISO 8601 defines date and time separated by "T".
Applications using this syntax may choose, for the sake of
readability, to specify a full-date and full-time separated by
(say) a space character.
It is interesting that the separator between date and time can be almost
anything - such an en dash as on IBM i? Lots of questions, perhaps. Not
things that make my work hard, but questions, nonetheless.
You mention MI functions - I've dabbled in CVTD and CVTT. They are very
powerful and flexible - lots of options and things to set for various
operations and conversions. There's also the CVTTS for timestamps -
didn't have a reason to use that yet.
Anyhow, hope I'm being helpful- although I'm still sure what and why
you're looking into this - but I don't need to know everything, right?
Cheers
Vern
On 10/16/2015 6:37 PM, Justin Dearing wrote:
On Fri, Oct 16, 2015 at 5:29 PM Matt Olson <Matt.Olson@xxxxxxxx> wrote:
As far as I know DB2 stores the date in ISO format if the file is
described with DDL (SQL).
It is not ISO 8601. 2015-10-16T15:04:30-04:00 is an ISO date time, DB2
wants 1981-04-28 00:00:00.0.
midrange.com
