It looks like this specific function chokes on the string which Google provides. For example:
Saturday, 2 December 2017 at 15:00:32 UTC
doesn't seem to parse, at least using the basex console with this function:
>
> xquery fn:parse-ietf-date("Wed, 6 Jun 94 07:29:35 GMT")
1994-06-06T07:29:35Z
Query executed in 0.82 ms.
>
> xquery fn:parse-ietf-date("Sat, 2 December 2017 15:00:32 UTC")
Stopped at ., 1/19:
[FORG0010] Invalid input ('-' expected, 'e' found): 'Sat, 2 December 2017 15:00:32 UTC'.
> xquery fn:parse-ietf-date("Sat, 2 Dec 2017 15:00:32 UTC")
2017-12-02T15:00:32Z
Query executed in 3.45 ms.
>
> xquery fn:parse-ietf-date("Sat, 2 Dec 2017 at 15:00:32 UTC")
Stopped at ., 1/19:
[FORG0010] Invalid input (time expected, 'a' found): 'Sat, 2 Dec 2017 at 15:00:32 UTC'.
>
> xquery fn:parse-ietf-date("Sat, 2 December 2017 15:00:32 UTC")
Stopped at ., 1/19:
[FORG0010] Invalid input ('-' expected, 'e' found): 'Sat, 2 December 2017 15:00:32 UTC'.
>
It looks like "at" causes havoc, as does a full month versus just an abbreviated month.
is this function able to parse this date? If not, what alternate function might be suitable?
Presumably Google's using a standard timestamp.
(data originates from "google hangouts" exported as JSON.)
When you look at the grammar of
fn:parse-ietf-date()
you notice not only the at but also the written out month is throwing the parser off; you could fix this usingfn:replace()
with a a regex like that:Demo