Base.Dates.ISO1123Format incorrect

[janssen]

Looking at Base.Dates, I see an exported DateFormat, RFC1123Format, which is invalid. It's missing the timezone field, which is present in, for example, HTTP response headers, and is explicitly part of the RFC 822 format referred by RFC 1123. This leads to errors, like this one:

julia> DateTime("Wed, 27 Jun 2018 00:19:54 GMT", RFC1123Format)
ERROR: ArgumentError: Found extra characters at the end of date time string
Stacktrace:
 [1] macro expansion at ./dates/parse.jl:103 [inlined]
 [2] tryparsenext_core(::String, ::Int64, ::Int64, ::DateFormat{Symbol("e, dd u yyyy HH:MM:SS"),Tuple{Base.Dates.DatePart{'e'},Base.Dates.Delim{String,2},Base.Dates.DatePart{'d'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'u'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'y'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'H'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'M'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'S'}}}, ::Bool) at ./dates/parse.jl:39
 [3] macro expansion at ./dates/parse.jl:153 [inlined]
 [4] tryparsenext_internal(::Type{DateTime}, ::String, ::Int64, ::Int64, ::DateFormat{Symbol("e, dd u yyyy HH:MM:SS"),Tuple{Base.Dates.DatePart{'e'},Base.Dates.Delim{String,2},Base.Dates.DatePart{'d'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'u'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'y'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'H'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'M'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'S'}}}, ::Bool) at ./dates/parse.jl:129
 [5] parse(::Type{DateTime}, ::String, ::DateFormat{Symbol("e, dd u yyyy HH:MM:SS"),Tuple{Base.Dates.DatePart{'e'},Base.Dates.Delim{String,2},Base.Dates.DatePart{'d'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'u'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'y'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'H'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'M'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'S'}}}) at ./dates/parse.jl:270
 [6] DateTime(::String, ::DateFormat{Symbol("e, dd u yyyy HH:MM:SS"),Tuple{Base.Dates.DatePart{'e'},Base.Dates.Delim{String,2},Base.Dates.DatePart{'d'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'u'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'y'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'H'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'M'},Base.Dates.Delim{Char,1},Base.Dates.DatePart{'S'}}}) at ./dates/io.jl:422

There would seem to be two reasonable options: either implement timezone support in Dates, or remove the RFC1123Format constant so that it doesn't mislead others as it misled me.

[nalimilan]

AFAIK time zone support will not be added to Dates to keep them simple, and there's the ZonedDateTime package for that. That said, I don't have an opinion regarding whether it should be removed or not.

[vtjnash]

RFC 822 / 1123 doesn't actually specify timezone support, it specifies a small list of special cases:

     zone        =  "UT"  / "GMT"                ; Universal Time
                                                 ; North American : UT
                 /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
                 /  "CST" / "CDT"                ;  Central:  - 6/ - 5
                 /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
                 /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
                 / ( ("+" / "-") 4DIGIT )        ; Local differential
                                                 ;  hours+min. (HHMM)

The last one (%z, +0000) is the recommended form in RFC 1123, the others "must" be supported for backwards compatibility, but no other timezones may be used.

One other approach that seems to be common enough is to only accept round-trip parsing of strftime from the local machine. For example, the FreeBSD 3.0 (e.g. macOS) libc documents the following restriction: 'The %Z format specifier only accepts time zone abbreviations of the local time zone, or the value "GMT".'

[janssen]

AFAIK time zone support will not be added to Dates to keep them simple

Unfortunately, there is nothing simple about dates :-). Time zones are a fact of life, and if the base Dates package includes supports for dates and times, it should be capable of handling them. But for the moment, removing the misleading & invalid RFC1123Format would be a step forward.

Adding full support for time zones (possibly by incorporating TimeZones.jl) is a much bigger step, I'd think; harder to take. And if it doesn't support "UT", "EST", "EDT", etc., (TimeZones doesn't) it still won't be RFC 822 compliant.

I'd think that the ability to parse email Date header values (e.g., "Tue, 26 Jun 2018 09:22:14 PDT") and HTTP Date header values (e.g., "Wed, 27 Jun 2018 16:30:05 GMT") would be a core requirement for any date-and-time package.

[janssen]

I had a thought... A DateFormat code letter could be added to Dates, perhaps 'I' for "Internet", which would match and parse only the RFC822 time zone formats. That would allow a proper RFC1123Format, which would allow the parsing of Internet timestamps. It would also not interfere with the more fastidious concerns of the TimeZones package.

[quinnj]

@omus, can you chime in w/ your thoughts here?

[omus]

I think the current behaviour of producing an error when time zone is provided what should happen give that Dates doesn't understand time zones. I'd prefer not to duplicate a subset of the functionality from TimeZones.jl to get this specific case working just with Dates.

With that said the RFC 822 / 1123 specification isn't fully supported with TimeZones either as Z is used to parse "UTC" while z is used to parse "+0100". I think this is another good use case for redesigning our parsing/formatting be more flexible than it is. Without getting to far into implementation details I see this as a format like "e, dd u yyyy HH:MM:SS [zZ]" to parse either specifier and also be able to pass in the subset of time zones to use for this format.