What are valid date-time separators in RFC3339 strings?

Question

I'm quite confused as to what's allowed as the time separator/designator in the RFC3339 standard. By time separator I mean the sequence of characters that draw the line between date and time.

The standard states in section 5.6 different things that are unclear or conflicting. First of all, it says that the production rule for a full datetime is this:

date-time = full-date "T" full-time

Meaning that the delimiter between the date and the time is an uppercase T. Right after comes this:

  NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in this
  syntax may alternatively be lower case "t" or "z" respectively

Meaning the upper case T may be a lower case t. It conflicts with the ABNF, but OK, it stills sounds to me within the realm of reasonable. Then the following is stated

  NOTE: ISO 8601 defines date and time separated by "T".
  Applications using this syntax may choose, for the sake of
  readability, to specify a full-date and full-time separated by
  (say) a space character.

Which is very confusing. Does this allow not only a space character but anything? which is what this say implies. Or does it by this syntax refer to ISO8601 and unnecessarily describes a detail of that other standard?

In other words, are the following valid RFC3339 strings?

• 2020-09-07 20:26:03.623359300+02:00
• 2020-09-07hey johnny20:26:03.623359300+02:00
• 2020-09-0720:26:03.623359300+02:00

Answer 1

Short answer: T (or t as discouraged alternative).

After reading on this as much as I could, it turns out the time separator must be a T or t. What has made think this way is first of all this thread in the GNU lists where F. Alexander Njemz contacted the authors of RFC3339 Graham Klyne and Chris Newman asking if T is mandatory and got this response from Mr. Klyne:

In short: "yes"

Per section 5.5, the intent in this draft was to specify a timestamp format using elements from and compatible with 8601, but eliminating as far as reasonable any variations that could make timestamp data harder to process. This includes making the 'T' mandatory in date+time values.

#g

Just for clarity's sake, this is stated in the section 5.5:

Simplicity is achieved by making most fields and punctuation mandatory.

This clearly clashes with a non-mandatory T and strongly makes me think that the this syntax in that problematic passage refers to ISO8601 and not RFC3339.

For those who want to read more, here are some links regarding the confusion created by this specific point:

• https://lists.gnu.org/archive/html/bug-coreutils/2006-05/msg00014.html
• http://validator.w3.org/feed/docs/error/InvalidRFC3339Date.html
• https://www.rfc-editor.org/errata/eid5783

Plus of course divergent implementations. For instance, the developers of GNU Date chose to use a space character:

$ date --rfc-3339=seconds
2020-09-14 14:53:51+02:00

Answer 2

Meaning the upper case T may be a lower case t. It conflicts with the ABNF, [...]

It does not. See 2.3 Terminal Values of RFC 2234:

Literal text strings are interpreted as a concatenated set of
printable characters.

   NOTE:     ABNF strings are case-insensitive and
             the character set for these strings is us-ascii.

So it is allowed to use t here.

  NOTE: ISO 8601 defines date and time separated by "T".
  Applications using this syntax may choose, for the sake of
  readability, to specify a full-date and full-time separated by
  (say) a space character.

Which is very confusing. Does this allow not only a space character but anything?

This "deviation" is used for readability to the user when displayed. So when the value is displayed to the user in some kind, it can be displayed as:

• 2020-09-07 20:26:03.623359300+02:00
• 2020-09-07, 20:26:03.623359300+02:00

That way it might be easier for the user to see the clear space between the date and time, so they don't have to look for the T or t character to find the separation. It is indeed a vague sentence as it basically mean the application can do anything.

To answer your question: These listed date formats are not valid according to RFC 3339.