我正在反对API，它要求RFC 1123日期。如果我发送的日期类似Thu, 04 Sep 2014 06:42:22 UTC的请求会因"UTC"部分而被拒绝。如果我操纵字符串并使时区部分"GMT"起作用。
我还注意到许多语言（Java，C＃，Python）使用时区字符串"GMT"格式化RFC 1123格式的UTC日期，但是我使用的语言Go保持为{{1 }}
我正在尝试了解它是否是语言错误，或者根据RFC不应使用"UTC"：http://www.ietf.org/rfc/rfc1123.txt
答案 0 :(得分：14)
使用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代替，如Jukka“Yucca”Korpela所讨论的here。在RFC 822发布几年后，ISO采用了该标准。 ISO 8601更为明智，并且正在现代协议和商业/工业中采用。
ISO 8601格式的例子：
2014-09-06T13:35:58-02:00
2014-09-06T15:35:58Z
如果与Go捆绑在一起的库正在为该格式生成UTC，我建议您提交错误报告。
仅供参考，Java包含业界领先的日期时间框架java.time类。这些类内置于Java 8及更高版本back-ported to Java 6 & 7和to 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等字符串。
请参阅此示例code live in 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 ) ;
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及更高版本中。这些类取代了麻烦的旧legacy日期时间类，例如java.util.Date，Calendar和＆amp; SimpleDateFormat
现在位于Joda-Time的maintenance mode项目建议迁移到java.time类。
要了解详情，请参阅Oracle Tutorial。并搜索Stack Overflow以获取许多示例和解释。规范是JSR 310。
您可以直接与数据库交换 java.time 对象。使用符合JDBC driver或更高版本的JDBC 4.2。不需要字符串，不需要java.sql.*类。
从哪里获取java.time类？
ThreeTen-Extra项目使用其他类扩展java.time。该项目是未来可能添加到java.time的试验场。您可以在此处找到一些有用的课程，例如Interval，YearWeek，YearQuarter和more。