I am working against an API and it requests RFC 1123 dates. If I send requests with a date like Thu, 04 Sep 2014 06:42:22 UTC
it gets rejected because of the "UTC"
part. If I manipulate the string and make the timezone part "GMT"
it works.
I also noticed that many languages (Java, C#, Python) are formatting the UTC dates in RFC 1123 format with timezone string "GMT"
however the language I'm using, Go, is keeping it as "UTC"
.
I'm trying to understand if it's a language bug or "UTC"
should not be used at all per RFC: http://www.ietf.org/rfc/rfc1123.txt
Summary This RFC is one of a pair that defines and discusses the requirements for Internet host software. This RFC covers the application and support protocols; its companion RFC-1122 covers the communication protocol layers: link layer, IP layer, and transport layer.
The Internet RFC 822 specification defines an electronic message format consisting of header fields and an optional message body. The header fields contain information about the message, such as the sender, the recipient, and the subject.
Use UT
or GMT
but not UTC
.
My reading of RFC 1123 is that it adopts RFC 822 for date-time formats except for tweaks.
RFC 822 does not contain the word UTC
. Instead page 25 refers to UT
being a synonym for GMT
. So you may be able to use UT
but not UTC
.
In addition, RFC 822 was superseded by RFC 2822 (yes, cute numbering). This spec only mentions UTC once, in defining time zone offsets. But this spec does not add UTC
as an identifier in the format. So same rule, use only GMT
or UT
in your strings.
This format defined by RFC 822 and 1123 is terrible. It is difficult to read, difficult to parse, assumes English language and culture, incorrectly defines the military time zones in the wrong direction, incorrectly equates UT with GMT, refers to Universal Time which is ambiguous as there are multiple kinds of UT with UTC being one, and encourages the bad practice of using the 3 or 4 letter codes for time zones which are neither standardized nor unique.
If at all possible, use ISO 8601 instead, as discussed here by Jukka “Yucca” Korpela. This standard was adopted by ISO a few years after RFC 822 was published. ISO 8601 is far more sensible, and is being adopted in modern protocols and in business/industry.
Examples of ISO 8601 format:
2014-09-06T13:35:58-02:00
2014-09-06T15:35:58Z
If a library bundled with Go is generating UTC
incorrectly for that format, I suggest you file a bug report.
FYI, Java includes an industry-leading date-time framework, the java.time classes. These classes are built into Java 8 and later, [back-ported to Java 6 & 7][5] and [to Android][6]. Available as open-source in the [OpenJDK][7] project.
The java.time classes use ISO 8601 formats by default when parsing/generating strings to represent their date-time values.
Furthermore, the [DateTimeFormatter
][8] class provides a formatter specifically for https://www.rfc-editor.org/rfc/rfc1123, DateTimeFormatter.RFC_1123_DATE_TIME
generating strings such as Tue, 3 Jun 2008 11:05:30 GMT
.
See this example [code live in IdeOne.com][9].
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
output: Tue, 15 Nov 2016 21:12:49 GMT
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date
, Calendar
, & SimpleDateFormat
.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.*
classes.
Where to obtain the java.time classes?
The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval
, YearWeek
, YearQuarter
, and more.
[5]: http://www.threeten.org/threetenbp/) [6]: https://github.com/JakeWharton/ThreeTenABP [7]: http://openjdk.java.net [8]: http://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html?is-external=true [9]: http://ideone.com/PI5vlu
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With