TO_CHAR Function for dates in UTF8 database

Question

Hi,
Our database is UTF8 enabled infact we are using AL32UTF8 encoding. When we are running the following query then the results are displayed in Japanese instead of English for the 'DAY' and 'DY' clause.
SELECT TO_CHAR(SYSDATE,'DAY') DAY,TO_CHAR(SYSDATE,'YEAR') YR,TO_CHAR(SYSDATE,'DY') DY,TO_CHAR(SYSDATE,'MON') MON FROM DUAL;
DAY YEAR DY MON
火曜日 TWO THOUSAND SIX 火 JAN
Can anyone please tell me what is the reason behind this. Our other nls parameters are like;-
SQL> sho parameter nls
NAME TYPE VALUE
nls_calendar string
nls_comp string
nls_currency string
nls_date_format string
nls_date_language string
nls_dual_currency string
nls_iso_currency string
nls_language string AMERICAN
nls_length_semantics string BYTE
nls_nchar_conv_excp string FALSE
nls_numeric_characters string
nls_sort string
nls_territory string AMERICA
nls_time_format string
nls_time_tz_format string
nls_timestamp_format string
nls_timestamp_tz_format string
Thanks & Regards,
Sudipta

Answer 1

The date literals I used are in the
ISO standard for date notation of YYYY-MM-DD so are internationally unambiguous.  The only circumstance I can envisage in which it would not return the rows expected would be the extremely unlikely one where all the rows with dates in the range happen
to have a date of 7 March 2015, and all have a non-zero time of day element.  There is no such thing in Access as a date value, only a date/time value so #2015-03-07# in fact represents the point of time at midnight at the start of 7 March 2015. 
Any rows with date/time values of that date, but with a non-zero time of day would consequently fall outside the range.
The above is so unlikely that I can't believe it to be the case, but the bullet-proof syntax would be:
    strCondition = "dtAllocation  >= #2015-02-06# " & _
          "AND dtAllocation < #2015-03-07#+1"
i.e. all date/time values on or later than the start of the first day of the range (#2015-02-06 00:00:00#) and before the start of the day following the end of the range (#2015-03-08 00:00:00#)
Assuming that the dtAllocation column is of date/time data type, and is returned as such in the report's RecordSource, not as a formatted string expression, I can see no reason on the information available why the above should not work, so if the report is
still not returning any data some other reason not apparent to us must be suspected.  We are not in a position to debug the report, however, so what that might be I can't say.
Ken Sheridan, Stafford, England