现象：在多语言环境下使用过Oracle的同学想必都遇到过这样一个问题，
date_v&">nbsp;date; date_v := to_date(‘2010/11/16′);–或’2010/11/16′
同一个服务器，不同Oracle clinet 不一定都行得通。
原因： 不指定转换字符串的情况下，Oracle使用既定的格式串进行日期转换操作，执行SELECT * FROM NLS_SESSION_PARAMETERS;察看NLS信息，其中NLS_DATE_FORMAT是指当前使用的格式化字符串。我这里是”DD-MON-RR”,dd代表日rr代表年mon代表月，所以to_date(‘2010/11/16′)==to_date(‘2010/11/16′,’DD-MON-RR’)，
MON在NLS_LANGUAGE为AMERICAN的情况下只识别Nov而不是别11，所以转换失败。
解决： 既然知道问题原因了，解决这个问题有三个方法。
1，更改NLS_LANGUAGE会使NLS_DATE_FORMAT同步为相应的格式。我们这里需要japanese格式。我通过增加环境变量（NLS_LANG=JAPANESE_JAPAN.JA16SJIS）实现。
NLS_DATE_FORMAT变成RR-MM-DD了，测试，select to_date(‘2010/11/15′) from dual–ok。
2，增加环境变量NLS_DATE_FORMAT（RR-MM-DD或yy-mm-dd或yy/mm/dd任何你需要的格式）。
测试，select to_date(‘2010/11/15′) from dual–ok。
这里要注意经过我测试，rr和yy是一个意思 ，连接符号-和/都可以使转换成功。
更改NLS_LANGUAGE或NLS_DATE_FORMAT的方法可以google以下．
到这里基本大功告成了，但是你也许会说我们不能随便修改Oracle client的这些配置，因为其他实例也许需要它！下面是第三个方法
3，to_date有个重载方法，提供转换需要的format。
无论NLS_DATE_FORMAT是什么，select to_date(‘2010/11/15′,’yy/mm/dd’) from dual–ok。
但是还是不要高兴过早了，select to_date(‘2010/nov/15′,’yy/mon/dd’) from dual–不一定ok。
当NLS_LANGUAGE环境为AMERICAN时是OK的，为East Asia language时mon格式符真正识别的是11月（这里japan和china还是不一样的，看起来是一个字，但是从我机器输入select to_date(‘2010/11月/15′,’yy/mon/dd’) from dual却出错。
具体细节可以参考文章http://www.eygle.com/special/NLS_CHARACTER_SET_05.htm
现在问题明白了，但解决方法这么多，难道转换一个字符串到日期真的这么周折？
我选择第三个方法，因为它是我能控制的。select to_date(‘2010/11/15′,’yy/mm/dd’) from dual–ok，因为mm的转译永远是阿拉伯数字啊。
案例：这样一个情景，现在有个存储要部署在未知地理未知服务器上，它需要一个date参数，plsql程序员想当然的吧它定义成了date，不巧，调用存储的另一个程序员是个想通过脚本来调用存储，并且通过windows计划任务触发脚本执行，这个脚本给了一个2010/11/15，看起来没任何问题，但是不巧这台应用服务器的Oracle客户端的NLS_LANGUAGE=AMERICAN，真是无巧不成书啊，当Oracle做这样一个调用前的参数转换工作的时候 date_v date; date_v := ‘2010/11/16’（这个转换是默认的不可控的）；灾难来临了。
怎么避免这样的灾难呢？参数改成nvarchar吧，自己做参数转换，使用上面我们的第三个解决方法data_v:= to_date(data_vchar,’yy/mm/dd’)，其实灾难可以避免。
有人会说，调用存储的人传了个2010￥/11……/16！怎么办，你的yyyy/mm/dd如何处理？当然没法处理，我的方法是给出一个准确的文档告诉对方参数应该是什么格式的，出错了也可以排除责任了。 另外我自己转换可以添加一些异常机制来提示问题，Oracle自动转换出错了可是很霸道的。