Hi All,
In my innocence I assumed that the ‘is ingresdate’ predicate would work using the current session setting of II_DATE_FORMAT. That variable can after all be set locally to override the global setting used in the installation. Given that many input date formats are valid in some settings but not in others, using the session setting makes sense to me.
So for example my installation has II_DATE_FORMAT=multinational4. So todays date would be generated as ‘06/04/2021’
But…
EXPORT II_DATE_FORMAT=SWEDEN
sql iidbdb <<SQL_END
select dbmsinfo(‘date_format’);
┌────────────────────────────────────────────────────────────────┐
│col1 │
├────────────────────────────────────────────────────────────────┤
│finland │
└────────────────────────────────────────────────────────────────┘
select date('today')\g
┌─────────────────────────┐
│col1 │
├─────────────────────────┤
│2021-04-06 │
└─────────────────────────┘
(1 row)
select case when '2021-04-06' is ingresdate then 'valid' else 'invalid' end\g
┌───────┐
│col1 │
├───────┤
│invalid│ ß Well that’s a bit of a shock.
└───────┘
(1 row)
select case when '06/04/2021' is ingresdate then 'valid' else 'invalid' end
┌───────┐
│col1 │
├───────┤
│valid │ß This is correct, as that date string is valid date input in Sweden
└───────┘
(1 row)
So is the ‘is ingresdate’ predicate only respecting the installation wide setting of II_DATE_FORMAT or is this a bug in the processing?
Note I’ve tried the above using the set date_format ‘sweden’ command with the same result.
Martin Bowes