oracle多语言环境下to_date时间转换问题

现象：在多语言环境下使用过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','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的转译永远是阿拉伯数字啊。

４， As a SQL function parameter. NLS parameters can be used explicitly to hardcode NLS behavior within a SQL function. Doing so will override the defaults set for the session in the initialization file, the client with environment variables, or set for the session by ALTER SESSION. For example:

	TO_CHAR('Mar 24 2011','MM  dd yyyy', 'nls_date_language = AMERICAN')

5,As initialization parameters on the server. You can include parameters in the initialization parameter file to specify a default session NLS environment. These settings have no effect on the client side; they control only the server's behavior. For example:

	NLS_TERRITORY = "CZECH REPUBLIC"

6,As ALTER SESSION parameters. NLS parameters set in an ALTER SESSION statement can be used to override the defaults set for the session in the initialization file, or set by the client with environment variables.

	SQL> ALTER SESSION SET NLS_SORT = FRENCH;

又增加了几个方法，最近在用sqlldr导从sybase出的一个csv时碰到问题，一列时间是 Mar 28 2011这样的，通过分析如果想导入到date列中只有在control文件的列配置中设置成这样 ：

。。。 

, record_date CHAR "to_date(:record_date,'MM dd yyyy','NLS_DATE_LANGUAGE=AMERICAN')"

。。。

最终导入成功，原理说白了就是“tell to SQLLOADER that I need to change his session”。

这个链接里有oracle关于nls方面的知识：http://download.oracle.com/docs/cd/A87860_01/doc/server.817/a76966/ch2.htm#91066

这里有些关于sqlldr load文件的高级资料 ：http://www.cnblogs.com/wzc998/archive/2011/03/24/1994137.html

案例：这样一个情景，现在有个存储要部署在未知地理未知服务器上，它需要一个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自动转换出错了可是很霸道的。

NLS是什么，可以看这里http://www.cnblogs.com/wzc998/archive/2010/11/17/1879652.html