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() 方法。
其他：返回的是local的时间，要不要用UTC时间？ :) （还有，文章时间戳貌似是服务器时间，东京时间？）
--
附，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位年份，实际上是造成了：
原先可能的针对getYear的y2k问题的补丁代码（如给返回值+1900）无法奏效，相反产生非预期的值。
掩盖了getYear的y2k问题，使得程序员继续使用本不该继续使用的getYear，而不是换到getFullYear方法上。
微软不遵循标准以及名不副实的“向后兼容”——尽管它有足够的资源：金钱和强人，但还是没有避免许多显而易见的inconformable和 incompatible，仅仅用草率或失误是不能令人信服的……切以为，这实际说明了其是通过其垄断地位制造事实标准进而加固其垄断。尽管基于此目的，开发文档要做好，开发工具要做好——让你更方便（更方便的做M$的奴隶？），但其骨子里其实是忽视开发人员（还未甘心做其奴隶的？）利益的。
