软件日期处理探研

软件中日期处理所存在的问题。其本质是客户机日期、应用程序服务器日期、数据库服务器日期的统一问题。

 

一、客户机 à 应用程序服务器

取得客户机表单元素日期的值，要服务器进行处理，则必须进行字符串到日期的转换。

这个转换过程一般是通过System.Convert.ToDateTime(string) 进行显示转换。

     Convert.ToDateTime 可以支持 年/月/日,月/日/年的转换。分隔符用"-","/","."都可以.

                        但对日/月/年的格式不能进行处理。

   如果是日期字符串转换为.Net FrameWork的DateTime 失败，会报以下错误

     该字符串未被识别为有效的 DateTime。

在.Net中文版，.Net英文版情况下测试结果一样。根据设断点跟踪提示.Net FrameWork中日期表述的格式是月/日/年。

  Convert.ToDateTime不能转换日/月/年的日期格式。    由此造成的影响是。系统不能处理输入日/月/年的格式。如果用户输入，则默认是转换成月/日/年 进行处理。如果转换不成功则抛出错误。对于.Net Framework 对日期处理的这种特性也是合理的。

 

二、应用程序服务器 à 客户机 ( 服务器端赋值)

 

系统中很多界面元素有初始值、多采用的是Date.ToShortDateString() 给页面元素赋值。这个短日期格式受服务器所设定的日期格式的约束，并不一定和客户机保持一致，这个时候需要设定格式字符串来设定一个日期格式。

 

本系统在设计之初，也考虑到了日期格式的问题。

PlentySoft.Ips.Common.IpsSysConst.DATE_FORMAT

public const string DATE_FORMAT = "YYYY-MM-DD";

设定了日期的格式，虽然这个格式是目前是在程序中写死了的。但也可很容易的改成由程序动态设定的。

IpsSysConst.DATE_FORMAT 也在很多模块中使用到了。但也在很多模块中没有用这个格式。在以前程序员的观念中，用到的地方仅只是用他去掉日期后面没有必要显示出来的时间。

 

 

三、其他系统对日期的处理方法

SAP Business One在系统设置里可以设定一个日期格式。以日期录入以这个设定的格式为准。输出也是采用这个格式。

QAD 的系统 是用日期控件限制日期的输入格式为 MM/DD/YY 系统的录入必须在这个合法的范围。

 

四、SQL Server2000数据库的日期格式

    在默认的配置下，一个日期的字符串在写入数据库的时候，和Convert.ToDateTime 差不多一样，数据库可以支持 年/月/日和月/日/年的隐试转换。分隔符用"-","/","."都可以被正确的识别。但对日/月/年的格式不能进行处理。

    如果是数据库中的日期转换出错。会报以下错误：

  从 char 数据类型到 datetime 数据类型的转换导致 datetime 值越界。语句已终止。

 

数据库的日期格式。只需设定参数就可以改变。以下是数据库中设定日期格式的例子。

SET DATEFORMAT mdy

GO

DECLARE @datevar datetime

SET @datevar = '12/31/98'

SELECT @datevar

GO

 

SET DATEFORMAT ydm

GO

DECLARE @datevar datetime

SET @datevar = '98/31/12'

SELECT @datevar

GO

 

SET DATEFORMAT ymd

GO

DECLARE @datevar datetime

SET @datevar = '98/12/31'

SELECT @datevar

GO

 

像这样的SQL语句是非常的不严谨的。

Select * from Table Where Date < '2004-12-22'

像这样的SQL也只有在特定的日期格式设定下才是正确的

Insert into Table (Date) values ('2004-1-25')

以上两个例子都有日期格式的问题、编程时要注意。

 

作为客户端的操作系统是五花八门的，每个用户的操作习惯也是千奇百怪的，如果没有对客户端输入的日期做限制，把客户端的日期直接塞到数据库里面去是非常危险的，程序运行不下去还是小问题，但如果是用户的意图是日/月/年(1/12/2000) 但系统的理解是月/日/年，那样数据就全乱套了。

 

应用程序服务器日期到数据库一般隐式的转换是正确的，不需要做什么额外处理。如果有特别日期格式的需求也只需要用格式字符串转一下再进行处理。

 

数据库的语言版本没有限制、可能存在的问题是某些默认的语言版本的日期格式不能满足需要，重新用SET DATEFORMAT设定一下格式就可以了。

 

 

五、系统现有问题的推荐解决方案

约定：要求服务器端不能采用DD/MM/YYYY的格式.

由于我们现在系统所有的日期都是通过日期控件来界面录入的。所以通过改进日期控件来限定死一个日期格式即可。

定为YYYY-MM-DD 的格式，这个改动只集中在控件一处,计划用时4天。主要难度是日期分隔符不可删。日期的取值，赋值问题。控件仿QAD的日期控件。

 

在日期的显示输出方面，在日期控件中日期的显示问题、DATAGRID中显示日期的问题和报表中日期显示的问题。要求必须使用统一的日期格式化字符串PlentySoft.Ips.Common.IpsSysConst.DATE_FORMAT格式化日期。目前的系统中有少量没有经过格式化就直接赋值的代码。主要表现在给日期控件赋值的部分。目前报表做得很少，据了解基本上还没用到日期的输出，以后如果用到了也要格式化。

 

优点：只要日期控件限制住了合法格式。服务器端的程序改动量很少。

缺点：服务器端系统不能采用日/月/年日期格式的系统。日期格式定死，不够人性化。

工作量：6人天

 

六、系统现有问题的最全面的解决方案:

在数据的录入方面。界面层-->业务逻辑层 采用客户机系统所设定的系统格式。或由登陆用户设定的格式录入日期数据。业务逻辑层要根据用户的设定解析出正确的日期。同时要根据服务器系统的日期格式设定。和数据库系统的日期设定。确立一套转化的通用方法调用。

在日期数据的显示方面，可以实现按不同用户的设定显示不同的日期格式。

优点：能充分尊重用户的操作习惯，因为我们的系统可能是在大陆和香港公司都使用同一套系统的，如果这样做的话可以使用户更加方便，也可以针对不同的用户出不同日期格式的报表。

缺点：改动量比较大，不仅是界面控件、已有的程序、底层代码的处理都会有改动。还要增加日期设定的模块。

工作量：保守估计，程序改动＋测试 需要1.5人月。