前端

img hax

M$可笑的“向后兼容”

发表于2004/9/30 12:33:00  1691人阅读

Bug描述:sfo日历上的年份在Mozilla下显示为104年而不是2004年。

Bug原因:年份是由calendar.js脚本所产生。

var cl_thisYear = cl_today.getYear();

使用了有y2k问题的getYear()方法。按照ecmascript ed3标准,返回的是YearFromTime(LocalTime(t)) − 1900. MS IE上之所以正常是因为JScript不合标准。

解决方案:改用 getFullYear() 方法。

 

附,JScript文档关于getYear()的说明:

这个方法已经过时,之所以提供这个方法,是为了保持向后的兼容性。请改用 getFullYear 方法。

对于1900-1999这段时间而言,返回的年份值是一个两位数字的整数,它代表了所保存的年份与 1900 年之间的差距。而对于其它的年份,返回值是一个四位的整数。例如,1996 年的返回值是 96,而 1825 和 2025 年的返回值则相应地为 1825 和 2025。

注意   对于 JScript 1.0 版,getYear 返回的值始终为 Date 对象中的年份与 1900 年之间的差距。例如,1899 年的返回值是 -1, 而 2000 年的返回值是 100。

 

注意MS的可笑之处,既然为了“保持向后的兼容性”,就不应该改变getYear在任何情况下的语义,因为它并不能预测早期代码是如何使用 getYear方法(及其可能的处理y2k问题的workaround)。而其貌似为大家方便的对1900-1999之外的年份返回4位年份,实际上是造成了:

  1. 原先可能的针对getYear的y2k问题的补丁代码(如给返回值+1900)无法奏效,相反产生非预期的值。
  2. 掩盖了getYear的y2k问题,使得程序员继续使用本不该继续使用的getYear,而不是换到getFullYear方法上。

微软不遵循标准以及名不副实的“向后兼容”——尽管它有足够的资源:金钱和强人,但还是没有避免许多显而易见的inconformable和 incompatible,仅仅用草率或失误是不能令人信服的……切以为,这实际说明了其是通过其垄断地位制造事实标准进而加固其垄断。尽管基于此目的,开发文档要做好,开发工具要做好——让你更方便(更方便的做M$的奴隶?),但其骨子里其实是忽视开发人员(还未甘心做其奴隶的?)利益的。

阅读全文
0 0

相关文章推荐

img
取 消
img