ISO-8601 parsing doesn't work with named timezones

[frabcus]

If I parse an ISO-8601 with a three letter timezone at the end, it comes out as invalid.

Curiously, if I call Date.parse then it works fine, which points to it being a bug in the extra browser-compatible ISO-8601 parser in moment.

> moment("2013-04-23 15:23:47 UTC").isValid()
false
> moment(Date.parse("2013-04-23 15:23:47 UTC")).isValid()
true
> moment("2013-04-23 15:23:47 UTC")
D {_i: "2013-04-23 15:23:47 UTC", _f: "YYYY-MM-DDTHH:mm:ss", _l: undefined, _isUTC: false, _a: Array[7]…}
> moment(Date.parse("2013-04-23 15:23:47 UTC"))
D {_i: 1366730627000, _f: undefined, _l: undefined, _isUTC: false, _d: Tue Apr 23 2013 16:23:47 GMT+0100 (BST)…}

[ichernev]

look at #162. Basically there is no reliable way to get time zone abbreviations. So there is no way we can parse them. I guess detecting them and passing them to the browser makes sense, but that won't work everywhere, for the same reason getting the zone abbr doesn't work.

[timrwood]

Hmm, it does look like a bug in the auto iso8601 parser.

moment("2013-04-23 15:23:47 UTC"); // this is equivalent to the following
moment("2013-04-23 15:23:47 UTC", "YYYY-MM-DDTHH:mm:ss");

Because the parser is finding the T in the zone at the end of the string instead of in between the DD and HH tokens, it is trimming off the 15:23:47 U part to get to the T. Then, because there is no data for the HH, mm, or ss, the parser is marking the date as invalid.

This is something I'll definitely add tests against.

Out of curiosity, where are you getting the input that contains the UTC at the end of the string? As far as I know, ISO 8601 only allows for "Z" or +-HH:mm timezone designations, not "UTC".

[frabcus]

Thanks!

Sorry, I've completely forgotten which of my datasets it was that had
that form of time in it :(

On Tue, May 28, 2013 at 05:46:02PM -0700, Tim Wood wrote:

Hmm, it does look like a bug in the auto iso8601 parser.

moment("2013-04-23 15:23:47 UTC"); // this is equivalent to the following
moment("2013-04-23 15:23:47 UTC", "YYYY-MM-DDTHH:mm:ss");

Because the parser is finding the T in the zone at the end of the string instead of in between the DD and HH tokens, it is trimming off the 15:23:47 U part to get to the T. Then, because there is no data for the HH, mm, or ss, the parser is marking the date as invalid.

This is something I'll definitely add tests against.

Out of curiosity, where are you getting the input that contains the UTC at the end of the string? As far as I know, ISO 8601 only allows for "Z" or +-HH:mm timezone designations, not "UTC".

---

Reply to this email directly or view it on GitHub:
#804 (comment)

[timrwood]

The commit above solves this problem by not adding a 'T' in the format string if there is not one in the input string. I added your specific use case as a unit test as well.