这是让我想到这一点的确切情况.
我有自动生成下一个逻辑项目编号的功能.该项目编号的一部分包括项目编号的创建年份.我们现在在2010年,所以日期中最重要的部分(为了我的项目编号)是"10"并且是两个字符长.如果我的程序碰巧在2009年执行,它是当前编码的方式,我会得到一个错误的项目编号,因为我的系统期望两位数的日期(10)而不是一个数字(9).
我的问题根本不是关于我的具体情况,是否做一个字符串操作是一个好主意:)但更多的是基于我的标题中陈述的原则.编写在历史记录中无法正常运行的软件是不是一个坏主意？您是否遇到过类似情况,您采取了什么路线？为什么？
完全有效的说,"我的程序不适用于历史数据." 在您的具体情况下,"历史数据"是2010年1月1日之前的内容.我强烈反对那些认为对您的代码施加此类限制通常是个坏主意的人.
我们每天都有这些限制.time_t例如,标准UNIX 的范围为正负68年左右.存储日期和时间的应用程序time_t不能代表1901-12-13之前或2030-01-19之后的日期.然而,使用该时间格式编写了数百万个应用程序.但我们没有听到有人认为那些节目有点不好.
构建应用程序完全是权衡.如果在最佳判断中没有必要涵盖过去或甚至将来某个任意点以外的日期,那就没关系了.这与设计一个只能容纳X个记录或使用1TB驱动器部署的系统没有什么不同,因为您知道最终在数据增长时必须进行升级.事实是,我们无法针对每一种可能性进行设计.
那些认为"Y2K错误"显示为什么你不应该对你的代码施加任意限制的人不会考虑事情.毕竟,4位数年份也是一个任意限制.如果我想在过去或将来代表一万年的日期怎么办？那个错误的Y10K bug!在某些时候,我们对我们支持的事物范围进行限制.
每个软件都有局限性.您可以选择适合您的应用程序的限制以及您将来如何看待它.