No reason not to support this; it should smell much like "TIMESTAMP WITH TIME ZONE" which you already have; This is Oracle type 232.
constant SQLT_TIMESTAMP is export = 187;
constant SQLT_TIMESTAMP_TZ is export = 188;
constant SQLT_TIMESTAMP_LTZ is export = 232; # new type
map it
+(SQLT_TIMESTAMP) => DateTime, # also new
+(SQLT_TIMESTAMP_TZ) => DateTime,
+(SQLT_TIMESTAMP_LTZ) => DateTimeL, # new perhaps a wrapper DateTime with custom behavior; TBD?
Then of course changes in StatementHandle.pm6 to improve expected formats OR ensure the session is forced to format will to ensure dates are ready for DateTime; I also think some will want a string and require no conversion. Especially if the data is going out an API; in such a case don't waste time factoring to a class just to recreate the string coming from Oracle.
No reason not to support this; it should smell much like "TIMESTAMP WITH TIME ZONE" which you already have; This is Oracle type 232.
constant SQLT_TIMESTAMP is export = 187; constant SQLT_TIMESTAMP_TZ is export = 188; constant SQLT_TIMESTAMP_LTZ is export = 232; # new type
map it
+(SQLT_TIMESTAMP) => DateTime, # also new +(SQLT_TIMESTAMP_TZ) => DateTime, +(SQLT_TIMESTAMP_LTZ) => DateTimeL, # new perhaps a wrapper DateTime with custom behavior; TBD?
Then of course changes in StatementHandle.pm6 to improve expected formats OR ensure the session is forced to format will to ensure dates are ready for DateTime; I also think some will want a string and require no conversion. Especially if the data is going out an API; in such a case don't waste time factoring to a class just to recreate the string coming from Oracle.