在多语言环境下使用过Oracle的同学想必都遇到过这样一个问题，

    date_v 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自动转换出错了可是很霸道的。