先从[url=https://jsr-310.dev.java.net/servlets/ProjectDocumentList?folderID=10338&expandFolder=10338&folderID=0]官网[/url]下载到JSR 310的参考实现:jsr-310-ri-0.6.3.jar, jsr-310-TZDB-all-0.6.3.jar
然后用Groovy来试玩一下
之前的一些对话:
[quote="t"]klauszou 说起来到现在我还真没见过哪个语言里有一个真正写的完全完善的公历的日期类 所以每次看到那些装逼说啥有自带类还用的着写吗的人就觉得想笑
klauszou 说来m$在这点上很有趣,知道自己写不好,于是干脆就把可能出问题的时间段都排除掉了www
rednaxelafx @klauszou Java的新Date Time API (JSR 310)或许还行?求评价
klauszou 没用过,不太清楚具体怎样,但你可以很简单的来验证,首先它有没有location参数,没有的就肯定不完善toka RT: @rednaxelafx: @klauszou Java的新Date Time API (JSR 310)或许还行?求评价
klauszou 举个简单的例子,不是所有国家都同时开始用格里历的,历史上来说包括英国,美国之类的国家直到18世纪才开始用,所以儒略格里补差计算定在1752年,而欧洲传统国家的补差计算是在1582年。而假设要涉及到时区则更加的复杂
rednaxelafx @klauszou 唔,那个例子我不知道该如何验证好。看到里面有这样的API,比单纯的offset貌似先进些 http://is.gd/jiN76
klauszou .@rednaxelafx 验证方法很简单,欧洲补差是1582年10月4日开始,补10天,即下一天为新历的10月15日。美国或者英国的话,则从1752年9月2日开始,补11天,即下一天是新历的9月14日。 粗略看了看,这个比大多数的都靠谱,不过应该还不是完善的。
klauszou .@rednaxelafx 这个的时区计算倒是相对很好了,几个特殊情况都考虑到了,不过在涉及location的问题上应该还是有问题[/quote]
于是看来JSR 310的参考实现还是考虑得不够周全?
JSR 310整个API用起来的感觉非常顺畅,比JDK现有的两套时间API好多了 :cry:
可惜Oracle不知道什么时候才会把它整合到JDK里去。JDK7多半是没指望了,JDK8恐怕也…
更新:
嗷,JSR-310的作者之一[url=http://www.jroller.com/scolebourne/entry/what_about_jsr_310]说他会继续开发JSR-310,并以Java SE 8为目标[/url]。好事啊!
然后用Groovy来试玩一下
D:\downloads>set JAVA_OPTS=-Xbootclasspath/p:jsr-310-ri-0.6.3.jar;jsr-310-TZDB-all-0.6.3.jar
D:\downloads>\sdk\groovy-1.7.2\bin\groovysh
Groovy Shell (1.7.2, JVM: 1.6.0_23)
Type 'help' or '\h' for help.
-----------------------------------------------------------------------
groovy:000> import javax.time.*
===> [import javax.time.*]
groovy:000> import javax.time.calendar.*
===> [import javax.time.*, import javax.time.calendar.*]
groovy:000> london = TimeZone.of("Europe/London")
===> Europe/London
groovy:000> date1 = ZonedDateTime.of(1752, 9, 2, 0, 0, 0, 0, london)
===> 1752-09-02T00:00-00:01:15[Europe/London]
groovy:000> date2 = date1.plus(Period.ofDays(1).withHours(8))
===> 1752-09-03T08:00-00:01:15[Europe/London]
groovy:000> date2.toLocalDate()
===> 1752-09-03
groovy:000> eastern = TimeZone.of("US/Eastern")
===> US/Eastern
groovy:000> date3 = ZonedDateTime.of(1752, 9, 2, 0, 0, 0, 0, eastern)
===> 1752-09-02T00:00-04:56:02[US/Eastern]
groovy:000> date4 = date3.plus(Period.ofDays(1).withHours(4), ZoneResolvers.retainOffset())
===> 1752-09-03T04:00-04:56:02[US/Eastern]
groovy:000> quit
之前的一些对话:
[quote="t"]klauszou 说起来到现在我还真没见过哪个语言里有一个真正写的完全完善的公历的日期类 所以每次看到那些装逼说啥有自带类还用的着写吗的人就觉得想笑
klauszou 说来m$在这点上很有趣,知道自己写不好,于是干脆就把可能出问题的时间段都排除掉了www
rednaxelafx @klauszou Java的新Date Time API (JSR 310)或许还行?求评价
klauszou 没用过,不太清楚具体怎样,但你可以很简单的来验证,首先它有没有location参数,没有的就肯定不完善toka RT: @rednaxelafx: @klauszou Java的新Date Time API (JSR 310)或许还行?求评价
klauszou 举个简单的例子,不是所有国家都同时开始用格里历的,历史上来说包括英国,美国之类的国家直到18世纪才开始用,所以儒略格里补差计算定在1752年,而欧洲传统国家的补差计算是在1582年。而假设要涉及到时区则更加的复杂
rednaxelafx @klauszou 唔,那个例子我不知道该如何验证好。看到里面有这样的API,比单纯的offset貌似先进些 http://is.gd/jiN76
klauszou .@rednaxelafx 验证方法很简单,欧洲补差是1582年10月4日开始,补10天,即下一天为新历的10月15日。美国或者英国的话,则从1752年9月2日开始,补11天,即下一天是新历的9月14日。 粗略看了看,这个比大多数的都靠谱,不过应该还不是完善的。
klauszou .@rednaxelafx 这个的时区计算倒是相对很好了,几个特殊情况都考虑到了,不过在涉及location的问题上应该还是有问题[/quote]
于是看来JSR 310的参考实现还是考虑得不够周全?
JSR 310整个API用起来的感觉非常顺畅,比JDK现有的两套时间API好多了 :cry:
可惜Oracle不知道什么时候才会把它整合到JDK里去。JDK7多半是没指望了,JDK8恐怕也…
更新:
嗷,JSR-310的作者之一[url=http://www.jroller.com/scolebourne/entry/what_about_jsr_310]说他会继续开发JSR-310,并以Java SE 8为目标[/url]。好事啊!