Date handling change w/upgrade

Question

Raj,
Hope all is well, I upgraded from htmldb 1.38 to 1.4.0.00.21c
Noticed dates are acting different...
Here is just one example...Before the upgrade, I had a validation function that worked
begin
if :P15_SDATE < sysdate - 10950
or :P15_EDATE < sysdate - 10950
or :p15_sdate > :P15_edate
then return false;
else
return true;
end if;
end;
after the upgrade it did not work, and returned invalid month errors....
The :p15_sdate and :p15_edate are date pickers in my native format (mm/dd/yyyy)...
After the upgrade it only worked if I changed the code and did a
to_date(:p15_sdate ,'MM/DD/YYYY')
and this is fine (I know I should be comparing dates to dates and already fixed the code)...but wondering if you know about this, why the change...and am I missing something I should/could be doing to make it better.
Thanks,
Meyer

Answer 1

though i'm pretty sure we've made no code changes to the way dates are handled in html db by default, there's a small chance that we're doing a better job of picking up the correct nls settings as determined by the Globalization options available on the application-level attributes page. to be honest, my hunch/hope is that you changed that "Application Language Derived From" attribute from the default "No NLS (Application not translated)" to "Browser (use browser language preference)". if your app's set to that "Browser (use browser language preference)", your nls_date_format will be set to the standard for your current language (in your case i'd guess that'd be en-us and dd-mon-yy, respectively). if your "Application Language Derived From" attribute is set "No NLS (Application not translated)", then we'd be using the nls_date_format of our database. so, assuming the date format of your db truly is 'MM/DD/YYYY' and your app is set up to provide no NLS support, i'm pretty sure you'd find that having a pl/sql region on a page in your app that did a...
htp.p (sysdate);
...would return something like...
10/01/2003
...if you then change your "Application Language Derived From" attribute to "Browser (use browser language preference)" and accessed your app from a browser using a primary language of "en-us" you'd find your pl/sql region returned a...
01-OCT-03
...or at least that's my take on this stuff. i'm pretty sure i'm on the right track, though. again, after talking to our development manager about this, i'm rather sure that nothing's changed on our part (with respect to default intended functionality). though there's the off chance that we're doing a better job of paying attention to your globalization prefs., my hope is that the prefs in your app have changed since you originally coded those pages.
hope this helps,
raj