- 浏览: 2584161 次
- 性别:
- 来自: 小胖儿的大城
文章分类
最新评论
-
ni4wangba0:
ni4wangba0 写道亲测,算法有问题。对不起,其实是我自 ...
谈谈"求线段交点"的几种算法(js实现,完整版) -
ni4wangba0:
亲测,算法有问题。
谈谈"求线段交点"的几种算法(js实现,完整版) -
kers007:
苹果不让Webapp 在appstore 里发布,我不知道对 ...
苹果真的要在 AppStore 里封杀 WebApp 吗? -
striveandlive:
fins = js大牛
[原创]GT-Template, 一个超轻量级的js模板工具. -
AlwaysYang:
基础扎实的才能行走天下。
关于body的"大小"在ie和ff下的一些基础知识
不知道各大语言 会不会加入对闰秒的处理
如果要加入的话 我觉得ruby和java 应该很快就会行动吧
==========
补充一下 : 我是指 2008年最新增加的这个闰秒
这是一个典型的自以为高深的伪问题。 任何一种语言都不会处理“闰秒”! 以Java为例: 1、getTime得到从1970年1月1日开始计算到 Date 对象中的时间之间的毫秒数。 2、System.currentTimeMillis()产生一个当前的毫秒,这个毫秒是自1970年1月1日0时起的毫秒数。 闰秒在哪儿处理?是在 毫秒数转换为时间 的时候处理,还是获取毫秒数的时候处理? 对任何一种语言来讲,它都只能按照它所能得到的数值按照固定的算法转换为时间,至于它得到的数值是否精确,是否处理过闰秒了,对语言本身来讲,都不是它应该关心的问题。 如果真的有哪种语言去处理闰秒,那可能就和网页代码中掺入sql语句一样难看,不是你这一层该管的事儿啊!!! (千年虫为什么要管?不用我解释了吧。。。 )
你这就是典型的自以为是的回答,
你这种总是以"上帝视角"说话的人实在让我很无奈.
元旦加班,不爽,见谅!
知道调整闰秒时授时中心是怎么发送时间的吗?它会这样发送:23:59:59 23:59:60 0:0:0……
语言这一层所要做的事情仅仅是:保证不把23:59:60认为是一个错误的值就行了,
任何一种语言,语言,语言啊,它怎么可能去处理闰秒,还是那一句话:不是你这一层该管的事儿啊!!!
技术人员的通病就是:自己钻了牛角尖总会死不承认,哈哈!
老兄,这事儿上,依我看来啊,还是你钻了牛角尖,不过这并不妨碍我佩服您,新年快乐!
这是一个典型的自以为高深的伪问题。 任何一种语言都不会处理“闰秒”! 以Java为例: 1、getTime得到从1970年1月1日开始计算到 Date 对象中的时间之间的毫秒数。 2、System.currentTimeMillis()产生一个当前的毫秒,这个毫秒是自1970年1月1日0时起的毫秒数。 闰秒在哪儿处理?是在 毫秒数转换为时间 的时候处理,还是获取毫秒数的时候处理? 对任何一种语言来讲,它都只能按照它所能得到的数值按照固定的算法转换为时间,至于它得到的数值是否精确,是否处理过闰秒了,对语言本身来讲,都不是它应该关心的问题。 如果真的有哪种语言去处理闰秒,那可能就和网页代码中掺入sql语句一样难看,不是你这一层该管的事儿啊!!! (千年虫为什么要管?不用我解释了吧。。。 )
你这就是典型的自以为是的回答,
你这种总是以"上帝视角"说话的人实在让我很无奈.
元旦加班,不爽,见谅!
知道调整闰秒时授时中心是怎么发送时间的吗?它会这样发送:23:59:59 23:59:60 0:0:0……
语言这一层所要做的事情仅仅是:保证不把23:59:60认为是一个错误的值就行了,
任何一种语言,语言,语言啊,它怎么可能去处理闰秒,还是那一句话:不是你这一层该管的事儿啊!!!
这个通常是库的问题,对标准库的处理不满意的话,可以自己改写(sun java支持用自己写的类有限制地替换jdk的类)
不过除了特殊领域的应用,闰秒完全不用去考虑,一般机器时钟的误差累积都大大超过了闰秒
考虑怎么处理闰秒,会使许多程序变得复杂,完全没有必要
就像一些项目中,年份限制在1901-2099之间,这个范围正好每4年一闰年,不存在百年4百年的修正,在一些时间段计算上要容易许多
不考虑闰秒,对业务没有影响,考虑它反而可能导致程序错误(60、61秒需要处理,等等),干脆就忽略它吧
对于需要处理闰秒的比如天文领域的软件,使用语言标准库的时间功能,一般是不合适的选择
比如时间范围不够,时间精度不够,历制太少等等
还是使用专用的时间库比较好,在那里支持闰秒就可以了
80/20原则
摘录一段 jdk 的api文档中 讲解Date类的部分 :
我的观点:
目前的"语言实现"上没有对闰秒做特殊处理, 但是很多语言在设计上应该是考虑到"闰秒"的, 至少java是如此(上面的英文为证).
注意红字Java implementations that actually track leap seconds correctly.
java不仅仅是运行在PC上的, 它也可能在一些特殊设备上运行 而且java也可以有多个版本的实现,
没有人敢保证"java100%的不处理闰秒", 也许某一天某一个特殊版本的java就会处理闰秒(或者已经有某个定制版本的java对闰秒进行了处理,只是我们无从知晓).
这个通常是库的问题,对标准库的处理不满意的话,可以自己改写(sun java支持用自己写的类有限制地替换jdk的类)
不过除了特殊领域的应用,闰秒完全不用去考虑,一般机器时钟的误差累积都大大超过了闰秒
考虑怎么处理闰秒,会使许多程序变得复杂,完全没有必要
就像一些项目中,年份限制在1901-2099之间,这个范围正好每4年一闰年,不存在百年4百年的修正,在一些时间段计算上要容易许多
不考虑闰秒,对业务没有影响,考虑它反而可能导致程序错误(60、61秒需要处理,等等),干脆就忽略它吧
这是一个典型的自以为高深的伪问题。 任何一种语言都不会处理“闰秒”! 以Java为例: 1、getTime得到从1970年1月1日开始计算到 Date 对象中的时间之间的毫秒数。 2、System.currentTimeMillis()产生一个当前的毫秒,这个毫秒是自1970年1月1日0时起的毫秒数。 闰秒在哪儿处理?是在 毫秒数转换为时间 的时候处理,还是获取毫秒数的时候处理? 对任何一种语言来讲,它都只能按照它所能得到的数值按照固定的算法转换为时间,至于它得到的数值是否精确,是否处理过闰秒了,对语言本身来讲,都不是它应该关心的问题。 如果真的有哪种语言去处理闰秒,那可能就和网页代码中掺入sql语句一样难看,不是你这一层该管的事儿啊!!! (千年虫为什么要管?不用我解释了吧。。。 )
你这就是典型的自以为是的回答,
你这种总是以"上帝视角"说话的人实在让我很无奈.
我就纳闷了 你从哪里看出来我"自以为高深"了? 我要是自以为高深我会发到海版?
另外 你去看一看jdk的api文档之后 再来说话.
( 你说那么多 就冲你的那句"任何一种语言都不会处理“闰秒”" 我就懒得往下看了. )
摘录一段 jdk 的api文档中 讲解Date类的部分 :
我的观点:
目前的"语言实现"上没有对闰秒做特殊处理, 但是很多语言在设计上应该是考虑到"闰秒"的, 至少java是如此(上面的英文为证).
注意红字Java implementations that actually track leap seconds correctly.
java不仅仅是运行在PC上的, 它也可能在一些特殊设备上运行 而且java也可以有多个版本的实现,
没有人敢保证"java100%的不处理闰秒", 也许某一天某一个特殊版本的java就会处理闰秒(或者已经有某个定制版本的java对闰秒进行了处理,只是我们无从知晓).
哈哈
其实,闰秒根本就不用处理
假设3年94608000秒多出一秒,你就当做系统时间每94608000秒慢一秒
平均到94608000,就是每秒慢1.05699307e-8秒,就是每秒误差不到11纳秒
这个完全可以忽略,哈哈
事实上,绝大部分机器,包括许多服务器,系统时钟的计时误差远远比11纳秒大的多
一般机器的时钟都是偏快,没有使用时钟同步的服务器,过一阵子就要手工把系统时间拨回
真郁闷,我宁可系统时间偏慢,也不要偏快,因为时间往回调,将导致许多程序对时间只增不减的假设失败
哈哈
其实,闰秒根本就不用处理
假设3年94608000秒多出一秒,你就当做系统时间每94608000秒慢一秒
平均到94608000,就是每秒慢1.05699307e-8秒,就是每秒误差不到11纳秒
这个完全可以忽略,哈哈
jsr对应日期 有些特别时间是硬编码的..
一个jsr要想通过.少说要用半年时间
PS:查查现行版本的jsr是否已经改过了.
你验证过 以前的闰秒 java没有做过处理吗?
如果要加入的话 我觉得ruby和java 应该很快就会行动吧
==========
补充一下 : 我是指 2008年最新增加的这个闰秒
评论
24 楼
yananay
2009-01-04
如果某一天地球突然南北极调转了怎么办呢?
如果某一天世界大战爆发了怎么办呢?
如果某一天地球毁灭了怎么办呢?
如果某一天异形进攻地球怎么办呢?
如果。。
如果。。
我想楼主应该加入 java 标准委员会,去着手解决这一系列艰巨而有深远意义的重大课题。
元旦快乐!
如果某一天世界大战爆发了怎么办呢?
如果某一天地球毁灭了怎么办呢?
如果某一天异形进攻地球怎么办呢?
如果。。
如果。。
我想楼主应该加入 java 标准委员会,去着手解决这一系列艰巨而有深远意义的重大课题。
元旦快乐!
23 楼
dazuiba
2009-01-04
进来之前,还从来没听说过 “闰秒”这一说。
被楼主科普了。
被楼主科普了。
22 楼
toostupid
2009-01-03
秒是怎么定义的?
硬件如何秒准?
年又怎么定义的?
我不太懂这个话题,不过总感觉似乎...没什么好办法完全解决。
硬件如何秒准?
年又怎么定义的?
我不太懂这个话题,不过总感觉似乎...没什么好办法完全解决。
21 楼
cqwonder
2009-01-02
cqwonder 写道
fins 写道
cqwonder 写道
这是一个典型的自以为高深的伪问题。 任何一种语言都不会处理“闰秒”! 以Java为例: 1、getTime得到从1970年1月1日开始计算到 Date 对象中的时间之间的毫秒数。 2、System.currentTimeMillis()产生一个当前的毫秒,这个毫秒是自1970年1月1日0时起的毫秒数。 闰秒在哪儿处理?是在 毫秒数转换为时间 的时候处理,还是获取毫秒数的时候处理? 对任何一种语言来讲,它都只能按照它所能得到的数值按照固定的算法转换为时间,至于它得到的数值是否精确,是否处理过闰秒了,对语言本身来讲,都不是它应该关心的问题。 如果真的有哪种语言去处理闰秒,那可能就和网页代码中掺入sql语句一样难看,不是你这一层该管的事儿啊!!! (千年虫为什么要管?不用我解释了吧。。。 )
你这就是典型的自以为是的回答,
你这种总是以"上帝视角"说话的人实在让我很无奈.
元旦加班,不爽,见谅!
知道调整闰秒时授时中心是怎么发送时间的吗?它会这样发送:23:59:59 23:59:60 0:0:0……
语言这一层所要做的事情仅仅是:保证不把23:59:60认为是一个错误的值就行了,
任何一种语言,语言,语言啊,它怎么可能去处理闰秒,还是那一句话:不是你这一层该管的事儿啊!!!
技术人员的通病就是:自己钻了牛角尖总会死不承认,哈哈!
老兄,这事儿上,依我看来啊,还是你钻了牛角尖,不过这并不妨碍我佩服您,新年快乐!
20 楼
cqwonder
2009-01-02
fins 写道
cqwonder 写道
这是一个典型的自以为高深的伪问题。 任何一种语言都不会处理“闰秒”! 以Java为例: 1、getTime得到从1970年1月1日开始计算到 Date 对象中的时间之间的毫秒数。 2、System.currentTimeMillis()产生一个当前的毫秒,这个毫秒是自1970年1月1日0时起的毫秒数。 闰秒在哪儿处理?是在 毫秒数转换为时间 的时候处理,还是获取毫秒数的时候处理? 对任何一种语言来讲,它都只能按照它所能得到的数值按照固定的算法转换为时间,至于它得到的数值是否精确,是否处理过闰秒了,对语言本身来讲,都不是它应该关心的问题。 如果真的有哪种语言去处理闰秒,那可能就和网页代码中掺入sql语句一样难看,不是你这一层该管的事儿啊!!! (千年虫为什么要管?不用我解释了吧。。。 )
你这就是典型的自以为是的回答,
你这种总是以"上帝视角"说话的人实在让我很无奈.
元旦加班,不爽,见谅!
知道调整闰秒时授时中心是怎么发送时间的吗?它会这样发送:23:59:59 23:59:60 0:0:0……
语言这一层所要做的事情仅仅是:保证不把23:59:60认为是一个错误的值就行了,
任何一种语言,语言,语言啊,它怎么可能去处理闰秒,还是那一句话:不是你这一层该管的事儿啊!!!
19 楼
javaeyebird
2009-01-02
javaeyebird 写道
这个通常是库的问题,对标准库的处理不满意的话,可以自己改写(sun java支持用自己写的类有限制地替换jdk的类)
不过除了特殊领域的应用,闰秒完全不用去考虑,一般机器时钟的误差累积都大大超过了闰秒
考虑怎么处理闰秒,会使许多程序变得复杂,完全没有必要
就像一些项目中,年份限制在1901-2099之间,这个范围正好每4年一闰年,不存在百年4百年的修正,在一些时间段计算上要容易许多
不考虑闰秒,对业务没有影响,考虑它反而可能导致程序错误(60、61秒需要处理,等等),干脆就忽略它吧
对于需要处理闰秒的比如天文领域的软件,使用语言标准库的时间功能,一般是不合适的选择
比如时间范围不够,时间精度不够,历制太少等等
还是使用专用的时间库比较好,在那里支持闰秒就可以了
80/20原则
18 楼
javaeyebird
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秒需要处理,等等),干脆就忽略它吧
17 楼
fins
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对闰秒进行了处理,只是我们无从知晓).
16 楼
cqwonder
2009-01-02
这是一个典型的自以为高深的伪问题。
任何一种语言都不会处理“闰秒”!
以Java为例:
1、getTime得到从1970年1月1日开始计算到 Date 对象中的时间之间的毫秒数。
2、System.currentTimeMillis()产生一个当前的毫秒,这个毫秒是自1970年1月1日0时起的毫秒数。
闰秒在哪儿处理?是在 毫秒数转换为时间 的时候处理,还是获取毫秒数的时候处理?
对任何一种语言来讲,它都只能按照它所能得到的数值按照固定的算法转换为时间,至于它得到的数值是否精确,是否处理过闰秒了,对语言本身来讲,都不是它应该关心的问题。
如果真的有哪种语言去处理闰秒,那可能就和网页代码中掺入sql语句一样难看,不是你这一层该管的事儿啊!!!
(千年虫为什么要管?不用我解释了吧。。。 )
任何一种语言都不会处理“闰秒”!
以Java为例:
1、getTime得到从1970年1月1日开始计算到 Date 对象中的时间之间的毫秒数。
2、System.currentTimeMillis()产生一个当前的毫秒,这个毫秒是自1970年1月1日0时起的毫秒数。
闰秒在哪儿处理?是在 毫秒数转换为时间 的时候处理,还是获取毫秒数的时候处理?
对任何一种语言来讲,它都只能按照它所能得到的数值按照固定的算法转换为时间,至于它得到的数值是否精确,是否处理过闰秒了,对语言本身来讲,都不是它应该关心的问题。
如果真的有哪种语言去处理闰秒,那可能就和网页代码中掺入sql语句一样难看,不是你这一层该管的事儿啊!!!
(千年虫为什么要管?不用我解释了吧。。。 )
15 楼
feilng
2009-01-02
闰秒问题是有病,时间只是运动,我们需要一种运动来作为参照衡量其他运动
既然我们选择了“原子时”,不能因为地球自转的不稳定来调整所谓的世界时,这是很不严肃的。
既然我们选择了“原子时”,不能因为地球自转的不稳定来调整所谓的世界时,这是很不严肃的。
14 楼
eyejava
2009-01-01
我怎么发现电脑一般都是偏慢的?
13 楼
javaeyebird
2009-01-01
javaeyebird 写道
insiku 写道
基本上不会处理润秒
润秒的产生是因为地球自转变慢
这东西太没规律
最近三次 98年 06年 09年
万一哪一天 爆发第三次世界大战 丢了10颗原子弹 造成润分钟的产生 是否要处理?
润秒的产生是因为地球自转变慢
这东西太没规律
最近三次 98年 06年 09年
万一哪一天 爆发第三次世界大战 丢了10颗原子弹 造成润分钟的产生 是否要处理?
哈哈
其实,闰秒根本就不用处理
假设3年94608000秒多出一秒,你就当做系统时间每94608000秒慢一秒
平均到94608000,就是每秒慢1.05699307e-8秒,就是每秒误差不到11纳秒
这个完全可以忽略,哈哈
事实上,绝大部分机器,包括许多服务器,系统时钟的计时误差远远比11纳秒大的多
一般机器的时钟都是偏快,没有使用时钟同步的服务器,过一阵子就要手工把系统时间拨回
真郁闷,我宁可系统时间偏慢,也不要偏快,因为时间往回调,将导致许多程序对时间只增不减的假设失败
12 楼
javaeyebird
2009-01-01
insiku 写道
基本上不会处理润秒
润秒的产生是因为地球自转变慢
这东西太没规律
最近三次 98年 06年 09年
万一哪一天 爆发第三次世界大战 丢了10颗原子弹 造成润分钟的产生 是否要处理?
润秒的产生是因为地球自转变慢
这东西太没规律
最近三次 98年 06年 09年
万一哪一天 爆发第三次世界大战 丢了10颗原子弹 造成润分钟的产生 是否要处理?
哈哈
其实,闰秒根本就不用处理
假设3年94608000秒多出一秒,你就当做系统时间每94608000秒慢一秒
平均到94608000,就是每秒慢1.05699307e-8秒,就是每秒误差不到11纳秒
这个完全可以忽略,哈哈
11 楼
insiku
2009-01-01
基本上不会处理润秒
润秒的产生是因为地球自转变慢
这东西太没规律
最近三次 98年 06年 09年
万一哪一天 爆发第三次世界大战 丢了10颗原子弹 造成润分钟的产生 是否要处理?
润秒的产生是因为地球自转变慢
这东西太没规律
最近三次 98年 06年 09年
万一哪一天 爆发第三次世界大战 丢了10颗原子弹 造成润分钟的产生 是否要处理?
10 楼
Nighthaven
2009-01-01
闰秒的问题非常麻烦,只需要稍稍考虑下就能猜出:社会上除了天文团体外都是集体选择不处理的(就当08年未多出一秒),在未来,当闰秒总数累计到比较可观的数量时,可能会着手集中解决。
9 楼
抛出异常的爱
2009-01-01
Saito 写道
这个闰秒问题早在 Java ruby 这些语言出现之前都已经存在..并且国际时间也调整过很多次了 好几十年了... 再说了..这么多年了都没纠正过..
假设有很多系统都基于时间差来做..你fix了之后.. 两个秒数之间突然多了一秒. 可能很多就直接当掉了. fix还不如不fix . 这不增加隐患么..
假设有很多系统都基于时间差来做..你fix了之后.. 两个秒数之间突然多了一秒. 可能很多就直接当掉了. fix还不如不fix . 这不增加隐患么..
jsr对应日期 有些特别时间是硬编码的..
fins 写道
其实 java是支持闰秒的
只是不知道sun的这个jdk实现是否支持
如果支持的话 它肯定是硬代码加上那一秒的
那么 08年这个最新的1秒 什么时候加呢
只是不知道sun的这个jdk实现是否支持
如果支持的话 它肯定是硬代码加上那一秒的
那么 08年这个最新的1秒 什么时候加呢
一个jsr要想通过.少说要用半年时间
PS:查查现行版本的jsr是否已经改过了.
8 楼
fins
2009-01-01
其实 java是支持闰秒的
只是不知道sun的这个jdk实现是否支持
如果支持的话 它肯定是硬代码加上那一秒的
那么 08年这个最新的1秒 什么时候加呢
只是不知道sun的这个jdk实现是否支持
如果支持的话 它肯定是硬代码加上那一秒的
那么 08年这个最新的1秒 什么时候加呢
7 楼
fins
2009-01-01
Saito 写道
这个闰秒问题早在 Java ruby 这些语言出现之前都已经存在..并且国际时间也调整过很多次了 好几十年了... 再说了..这么多年了都没纠正过..
假设有很多系统都基于时间差来做..你fix了之后.. 两个秒数之间突然多了一秒. 可能很多就直接当掉了. fix还不如不fix . 这不增加隐患么..
假设有很多系统都基于时间差来做..你fix了之后.. 两个秒数之间突然多了一秒. 可能很多就直接当掉了. fix还不如不fix . 这不增加隐患么..
你验证过 以前的闰秒 java没有做过处理吗?
6 楼
Saito
2009-01-01
这个闰秒问题早在 Java ruby 这些语言出现之前都已经存在..并且国际时间也调整过很多次了 好几十年了... 再说了..这么多年了都没纠正过..
假设有很多系统都基于时间差来做..你fix了之后.. 两个秒数之间突然多了一秒. 可能很多就直接当掉了. fix还不如不fix . 这不增加隐患么..
假设有很多系统都基于时间差来做..你fix了之后.. 两个秒数之间突然多了一秒. 可能很多就直接当掉了. fix还不如不fix . 这不增加隐患么..
5 楼
weiqingfei
2009-01-01
几点了都,怎么还不睡觉。
发表评论
-
有些事现在不做,一辈子都不会做了
2012-03-27 20:49 4827和当初那篇《Done ... -
小胖的" MacOS常用免费软件 "清单(有小更新).
2011-09-13 18:16 10661转眼用MacOS也有一年多 ... -
上海HP招Web前端工程师一名, 有意者简历 发到 fins[圈a]163.com
2011-05-26 17:04 608上海HP招Web前端工程师一名, 有意者简历 发到 fins[ ... -
如今锻炼身体越来越难,暂时把微博转到国内的新浪微博了,欢迎关注.
2011-03-14 10:12 1641如今锻炼身体越来越难,暂时把微博转到国内的新浪微博了,欢迎关注 ... -
简单说说1月8号的中国首届cocoa移动开发者大会吧.
2011-01-09 02:28 2551这次大会是我的治愈系小天使@tinyfool (他就是那个重量 ... -
离职离了一个月了,还没离,而且被派到广州来了...
2010-12-05 23:55 2004离职离了一个月了,还没离,而且被派到广州来了... 出差加班中 ... -
离职中...
2010-11-16 13:03 2136到上海三年多 ,感谢普元给了我一个很好的成长环境, 让我学到了 ... -
推特碎语摘记,关于HTML5 Webworker(临时)
2010-04-19 09:27 2325把推特里自己说过的关 ... -
向那些伟大的 无懈可击的观点致敬
2010-04-13 15:51 2068世界上有一些观点是无懈可击的 是伟大而完美的. 是值得我们膜拜 ... -
google离开后 我开始重新玩 twitter 了 : @finscn
2010-04-06 18:37 1810google离开后 我开始恢复上twitter了 欢迎大家f ... -
转两篇关于"前端工程师面试"的文章,其实不仅仅适于前端工程师
2010-04-01 10:48 2416原作者是 Nicholas C. Zakas 下面给出的链接 ... -
<你嘴上所说的人生就是你的人生>
2010-03-31 15:43 1596朋友给我发来了一段话,出自这本书: <你嘴上所说的人生就 ... -
推荐大家一款小巧的国产思维导图(脑图软件):Thinking Express
2010-03-26 18:22 4772很久以前 善用佳软上就 ... -
有人玩<名将三国Q>吗? ( 不是<名将三国> )
2010-01-16 14:46 2270有人玩<名将三国Q>吗? ( 不是<名将三国 ... -
有了解相机的朋友吗?帮忙看看这款是徕卡的什么型号 谢谢了
2010-01-15 22:50 1403有了解相机的朋友吗?帮忙看看这款是徕卡的什么型号(上世纪40年 ... -
[求开导]明天又是星期二... 颤抖...
2010-01-11 18:41 2183我一直自认还算是一个 ... -
只说几句
2009-05-20 18:21 1642最近琐事太多 依然无暇去做所谓的正经事, 但是还是想上来说几句 ... -
我最近正在看的一本英语教材,我的英语水平由此可见一斑哦...
2009-04-12 22:08 4617最近打算在上下班的地铁里学学英语 可是我英语水平实在太低下了 ... -
我爱上了一个女孩... (此文标题党)
2009-04-11 12:00 2393她叫 冈田技兰 , 是胖虎/技安(过去叫 大熊)的妹妹. ... -
永远不要低估胖子---哦 不对, 是皮克斯的心
2009-04-07 15:38 1657刚刚在 影像日报 看到了这篇文章: 1.75亿打造,皮克斯《 ...
相关推荐
关于2015年6月30日 NTP 闰秒测试结果说明,里面给出了相关的测试结果。
处理TerraSync SSF数据 - 本教程介绍如何将Trimble标准存储格式文件(.ssf)与适当的参考/基站RINEX文件一起导入TBC,并执行连续GNSS数据的后处理以创建轨迹准确定位记录的特征点和线条工作。 使用点云 使用点云 - ...
用于审计 Ubuntu 服务器以解决闰秒问题的脚本 背景 2015 年 7 月 1 日,全球原子钟将增加闰秒,以将原子时与太阳时对齐。 此过程最后一次执行是在 2012 年 7 月 1 日,并导致许多 Linux 服务器出现问题。 从那时起...
减少世界时闰秒调整频率的原子时秒长调整方法研究.docx
闰秒”惹的祸?亚马逊AWS服务出现大面积宕机.docx
飞跃实验室工具 用于闰秒监控和处理的有用工具 这是我在闰秒模拟中使用的一组工具。 它们最初于 2012 年开发,并在 2015 年略有改进。 请参阅每个目录中的 README.md 文件以获取说明。
TBC数据处理使用教程,含数据输入输出,基线解算,平差计算等
闰秒测试工具 最新更新:2015 年 5 月 1 日 初始版本: ... 当闰秒 (LS) 发生时,这种差异会发生变化。 网络时间协议 (NTP) 是用于计算机系统之间时钟同步的网络协议。 NTP 提供 UTC 时间。 国际地球自
%GPS2UTC 将 GPS 时间标签转换为 UTC(GMT) 时间,考虑闰秒% GPS2UTC(date) 更正 GPS 日期数组(任何 matlab 格式) % 闰秒并返回一个 UTC 日期数组,其中: % UTC = GPS - 步进时间% 当前步骤时间是到 2009 年 1 月 ...
该文档主要介绍了美国天宝TBC2.4软件进行GPS数据处理的流程,便于内业人员快速掌握GPS高精度数据处理。
2015年6月30日会产生闰秒的问题(正闰秒,相关知识点请自行百度或谷歌),我们公司客户需要知道相关设备是否受该问题影响,导致系统宕机或重启,为此我做了相关调查,这部分是NTP相关参数的说明。
%UTC2GPS 将 UTC(GMT) 时间标签转换为 GPS 时间占闰秒% UTC2GPS(date) 校正 UTC 日期数组(任何 matlab 格式) % 闰秒并返回 GPS 日期数组,其中: % GPS = UTC + 步进时间% 当前步骤时间是到 2009 年 1 月 1 日,但...
TBC软件培训教程
尽管它是稳定和成熟的,但我们可能会根据反馈更改API的详细信息。 尽管这不是Google官方支持的产品,但是您可以在无与我们。 API概述 Unsmear的API可与Abseil一起使用,并且非常相似。 它使用absl::Time作为absl::...
GPS UTC与北京时间的转换函数,很好用!给大家分享!
提供了多语言多时区真实解决方案(动态语言包,时区,夏令时,闰秒) 提供了数据库版本和数据版本管理(表变更变多了,数据维护多了) 安排了一套油腻的约定和工程实践(枚举类,配置文件,模板等约定) 解决了软件...
matlab开发-utctogpstimecoverter公司。将UTC(GMT)时间标签转换为占闰秒的GPS时间
GPS UTC与北京时间的转换函数,方便使用。
Unix timestamp:是从1970年1月1日(UTC/GMT的午夜)开始所经过的秒数,不考虑闰秒 import datetime import time print time.mktime(datetime.datetime.now().timetuple()) 输出为: 1431674373.0 PS:这里再为大家...
pyqt开发的简单界面,支持bds/gps与utc时间互转,显示北京时间,闰秒可设置。