Is "UTC" a valid timezone name for RFC 1123 specification?

AhmetB - Google picture AhmetB - Google · Sep 4, 2014 · Viewed 7.4k times · Source

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

Answer

Basil Bourque picture Basil Bourque · Sep 8, 2014

Short Answer

Use UT or GMT but not UTC.

RFC 1123

My reading of RFC 1123 is that it adopts RFC 822 for date-time formats except for tweaks.

RFC 822

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.

RFC 2822

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.

ISO 8601

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

Programming

If a library bundled with Go is generating UTC incorrectly for that format, I suggest you file a bug report.

java.time

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 and to Android. Available as open-source in the OpenJDK project.

The java.time classes use ISO 8601 formats by default when parsing/generating strings to represent their date-time values.

Furthermore, the DateTimeFormatter class provides a formatter specifically for http://tools.ietf.org/html/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.

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


About java.time

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.