Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

Tags:

datetime

rfc

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

like image 860
ahmet alp balkan Avatar asked Sep 04 '14 06:09

ahmet alp balkan


People also ask

What RFC 1123?

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.

What RFC 822?

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.


1 Answers

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][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


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?

  • Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
  • Java 9 adds some minor features and fixes.
  • Java SE 6 and Java SE 7
  • Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
  • Android
  • Later versions of Android bundle implementations of the java.time classes.
  • For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….

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

like image 144
Basil Bourque Avatar answered Oct 05 '22 21:10

Basil Bourque