|
锁定老帖子 主题：很想知道哪个语言会最先处理"闰秒"问题
精华帖 (0) :: 良好帖 (0) :: 灌水帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-01-01
最后修改：2009-01-01
闰秒的问题非常麻烦，只需要稍稍考虑下就能猜出：社会上除了天文团体外都是集体选择不处理的（就当08年未多出一秒），在未来，当闰秒总数累计到比较可观的数量时，可能会着手集中解决。
|
| 返回顶楼 | |
|
发表时间：2009-01-01
基本上不会处理润秒
润秒的产生是因为地球自转变慢 这东西太没规律 最近三次 98年 06年 09年 万一哪一天 爆发第三次世界大战 丢了10颗原子弹 造成润分钟的产生 是否要处理? |
| 返回顶楼 | |
|
发表时间：2009-01-01
insiku 写道 基本上不会处理润秒
润秒的产生是因为地球自转变慢 这东西太没规律 最近三次 98年 06年 09年 万一哪一天 爆发第三次世界大战 丢了10颗原子弹 造成润分钟的产生 是否要处理? 哈哈 其实，闰秒根本就不用处理 假设3年94608000秒多出一秒，你就当做系统时间每94608000秒慢一秒 平均到94608000，就是每秒慢1.05699307e-8秒，就是每秒误差不到11纳秒 这个完全可以忽略，哈哈 |
| 返回顶楼 | |
|
发表时间：2009-01-01
javaeyebird 写道 insiku 写道 基本上不会处理润秒
润秒的产生是因为地球自转变慢 这东西太没规律 最近三次 98年 06年 09年 万一哪一天 爆发第三次世界大战 丢了10颗原子弹 造成润分钟的产生 是否要处理? 哈哈 其实，闰秒根本就不用处理 假设3年94608000秒多出一秒，你就当做系统时间每94608000秒慢一秒 平均到94608000，就是每秒慢1.05699307e-8秒，就是每秒误差不到11纳秒 这个完全可以忽略，哈哈 事实上，绝大部分机器，包括许多服务器，系统时钟的计时误差远远比11纳秒大的多 一般机器的时钟都是偏快，没有使用时钟同步的服务器，过一阵子就要手工把系统时间拨回 真郁闷，我宁可系统时间偏慢，也不要偏快，因为时间往回调，将导致许多程序对时间只增不减的假设失败 |
| 返回顶楼 | |
|
发表时间：2009-01-01
我怎么发现电脑一般都是偏慢的？
|
| 返回顶楼 | |
|
发表时间：2009-01-02
闰秒问题是有病，时间只是运动，我们需要一种运动来作为参照衡量其他运动
既然我们选择了“原子时”，不能因为地球自转的不稳定来调整所谓的世界时，这是很不严肃的。 |
| 返回顶楼 | |
|
发表时间：2009-01-02
这是一个典型的自以为高深的伪问题。
任何一种语言都不会处理“闰秒”！ 以Java为例： 1、getTime得到从1970年1月1日开始计算到 Date 对象中的时间之间的毫秒数。 2、System.currentTimeMillis()产生一个当前的毫秒，这个毫秒是自1970年1月1日0时起的毫秒数。 闰秒在哪儿处理？是在 毫秒数转换为时间 的时候处理，还是获取毫秒数的时候处理？ 对任何一种语言来讲，它都只能按照它所能得到的数值按照固定的算法转换为时间，至于它得到的数值是否精确，是否处理过闰秒了，对语言本身来讲，都不是它应该关心的问题。 如果真的有哪种语言去处理闰秒，那可能就和网页代码中掺入sql语句一样难看，不是你这一层该管的事儿啊！！！ （千年虫为什么要管？不用我解释了吧。。。 ） |
| 返回顶楼 | |
|
发表时间：2009-01-02
最后修改：2009-01-02
cqwonder 写道 这是一个典型的自以为高深的伪问题。 任何一种语言都不会处理“闰秒”！ 以Java为例： 1、getTime得到从1970年1月1日开始计算到 Date 对象中的时间之间的毫秒数。 2、System.currentTimeMillis()产生一个当前的毫秒，这个毫秒是自1970年1月1日0时起的毫秒数。 闰秒在哪儿处理？是在 毫秒数转换为时间 的时候处理，还是获取毫秒数的时候处理？ 对任何一种语言来讲，它都只能按照它所能得到的数值按照固定的算法转换为时间，至于它得到的数值是否精确，是否处理过闰秒了，对语言本身来讲，都不是它应该关心的问题。 如果真的有哪种语言去处理闰秒，那可能就和网页代码中掺入sql语句一样难看，不是你这一层该管的事儿啊！！！ （千年虫为什么要管？不用我解释了吧。。。 ） 你这就是典型的自以为是的回答, 你这种总是以"上帝视角"说话的人实在让我很无奈. 我就纳闷了 你从哪里看出来我"自以为高深"了? 我要是自以为高深我会发到海版? 另外 你去看一看jdk的api文档之后 再来说话. ( 你说那么多 就冲你的那句"任何一种语言都不会处理“闰秒”" 我就懒得往下看了. ) 摘录一段 jdk 的api文档中 讲解Date类的部分 : 引用 A second is represented by an integer from 0 to 61; the values 60 and 61 occur only for leap seconds and even then only in Java implementations that actually track leap seconds correctly. Because of the manner in which leap seconds are currently introduced, it is extremely unlikely that two leap seconds will occur in the same minute, but this specification follows the date and time conventions for ISO C.
我的观点: 目前的"语言实现"上没有对闰秒做特殊处理, 但是很多语言在设计上应该是考虑到"闰秒"的, 至少java是如此(上面的英文为证). 注意红字Java implementations that actually track leap seconds correctly. java不仅仅是运行在PC上的, 它也可能在一些特殊设备上运行 而且java也可以有多个版本的实现, 没有人敢保证"java100%的不处理闰秒", 也许某一天某一个特殊版本的java就会处理闰秒(或者已经有某个定制版本的java对闰秒进行了处理,只是我们无从知晓). |
| 返回顶楼 | |
|
发表时间：2009-01-02
最后修改：2009-01-02
引用 摘录一段 jdk 的api文档中 讲解Date类的部分 : 引用 A second is represented by an integer from 0 to 61; the values 60 and 61 occur only for leap seconds and even then only in Java implementations that actually track leap seconds correctly. Because of the manner in which leap seconds are currently introduced, it is extremely unlikely that two leap seconds will occur in the same minute, but this specification follows the date and time conventions for ISO C.
我的观点: 目前的"语言实现"上没有对闰秒做特殊处理, 但是很多语言在设计上应该是考虑到"闰秒"的, 至少java是如此(上面的英文为证). 注意红字Java implementations that actually track leap seconds correctly. java不仅仅是运行在PC上的, 它也可能在一些特殊设备上运行 而且java也可以有多个版本的实现, 没有人敢保证"java100%的不处理闰秒", 也许某一天某一个特殊版本的java就会处理闰秒(或者已经有某个定制版本的java对闰秒进行了处理,只是我们无从知晓). 这个通常是库的问题，对标准库的处理不满意的话，可以自己改写（sun java支持用自己写的类有限制地替换jdk的类） 不过除了特殊领域的应用，闰秒完全不用去考虑，一般机器时钟的误差累积都大大超过了闰秒 考虑怎么处理闰秒，会使许多程序变得复杂，完全没有必要 就像一些项目中，年份限制在1901-2099之间，这个范围正好每4年一闰年，不存在百年4百年的修正，在一些时间段计算上要容易许多 不考虑闰秒，对业务没有影响，考虑它反而可能导致程序错误（60、61秒需要处理，等等），干脆就忽略它吧 |
| 返回顶楼 | |
|
发表时间：2009-01-02
最后修改：2009-01-02
javaeyebird 写道 这个通常是库的问题，对标准库的处理不满意的话，可以自己改写（sun java支持用自己写的类有限制地替换jdk的类） 不过除了特殊领域的应用，闰秒完全不用去考虑，一般机器时钟的误差累积都大大超过了闰秒 考虑怎么处理闰秒，会使许多程序变得复杂，完全没有必要 就像一些项目中，年份限制在1901-2099之间，这个范围正好每4年一闰年，不存在百年4百年的修正，在一些时间段计算上要容易许多 不考虑闰秒，对业务没有影响，考虑它反而可能导致程序错误（60、61秒需要处理，等等），干脆就忽略它吧 对于需要处理闰秒的比如天文领域的软件，使用语言标准库的时间功能，一般是不合适的选择 比如时间范围不够，时间精度不够，历制太少等等 还是使用专用的时间库比较好，在那里支持闰秒就可以了 80/20原则 |
| 返回顶楼 | |
