我正在反对API,它要求RFC 1123日期.如果我发送的请求有一个日期 Thu, 04 Sep 2014 06:42:22 UTC,因为该"UTC"部分会被拒绝.如果我操纵字符串并使时区部分"GMT"工作.
我还注意到许多语言(Java,C#,Python)使用时区字符串格式化RFC 1123格式的UTC日期,"GMT"但是我正在使用的语言Go将其保留为"UTC".
我试图了解它是否是一种语言错误,或者"UTC"根本不应该根据RFC使用:http://www.ietf.org/rfc/rfc1123.txt
Bas*_*que 16
使用UT或GMT不使用UTC.
我对RFC 1123的解读是它采用RFC 822作为日期时间格式,除了调整.
RFC 822不包含该单词UTC.相反,第25页指的是UT作为的同义词GMT.所以你可以使用UT但不能UTC.
此外,RFC 822被RFC 2822取代(是的,可爱的编号).此规范仅在定义时区偏移时提及UTC一次.但是此规范不会UTC在格式中添加标识符.同样的规则,只使用GMT或UT在你的字符串中使用.
RFC 822和1123定义的这种格式非常糟糕.难以阅读,难以解析,假设英语语言和文化,错误地将军事时区定义错误方向,错误地将UT与GMT等同,指的是通用时间,这是模糊的,因为有多种UT与UTC是一,并鼓励使用3或4个字母代码进行既不标准化也不唯一的时区的不良做法.
如果可能的话,使用ISO 8601来代替,如讨论这里的尤卡"尤卡" Korpela.在RFC 822发布几年后,ISO采用了该标准.ISO 8601更为明智,并且正在现代协议和商业/工业中采用.
ISO 8601格式的示例:
2014-09-06T13:35:58-02:00
2014-09-06T15:35:58Z
Run Code Online (Sandbox Code Playgroud)
如果与Go捆绑在一起的库生成的UTC格式不正确,我建议您提交错误报告.
仅供参考,Java包含业界领先的日期时间框架java.time类.这些类内置于Java 8及更高版本中,后端移植到Java 6和7以及Android.在OpenJDK项目中作为开源提供.
在解析/生成字符串以表示其日期时间值时,java.time类默认使用ISO 8601格式.
此外,DateTimeFormatter该类提供了一个专门用于http://tools.ietf.org/html/rfc1123的格式化程序,DateTimeFormatter.RFC_1123_DATE_TIME生成字符串,如Tue, 3 Jun 2008 11:05:30 GMT.
在IdeOne.com中查看此示例代码.
Instant instant = Instant.now() ; // Current moment in UTC.
OffsetDateTime odt = instant.atOffset( ZoneOffset.UTC ) ; // A wrapper around Instant, more flexible such as formatting.
DateTimeFormatter f = DateTimeFormatter.RFC_1123_DATE_TIME ;
String output = odt.format( f ) ;
Run Code Online (Sandbox Code Playgroud)
instant.toString():2016-11-15T21:12:49.261Z
odt.toString():2016-11-15T21:12:49.261Z
输出:2016年11月15日星期二21:12:49 GMT
该java.time框架是建立在Java 8和更高版本.这些类取代麻烦的老传统日期时间类,如java.util.Date,Calendar,和SimpleDateFormat.
现在处于维护模式的Joda-Time项目建议迁移到java.time类.
要了解更多信息,请参阅Oracle教程.并搜索Stack Overflow以获取许多示例和解释.规范是JSR 310.
您可以直接与数据库交换java.time对象.使用符合JDBC 4.2或更高版本的JDBC驱动程序.不需要字符串,不需要课程.java.sql.*
从哪里获取java.time类?
该ThreeTen-额外项目与其他类扩展java.time.该项目是未来可能添加到java.time的试验场.您可以在此比如找到一些有用的类Interval,YearWeek,YearQuarter,和更多.
| 归档时间: |
|
| 查看次数: |
6207 次 |
| 最近记录: |