Unfortunately, the JavaScript methods Date.parse() or new Date() cannot parse Date-Strings like that one:
2021-03-16T10:54:47.037+01 //ERROR!!
(even though it's proper ISO-8601) The correct format is
2021-03-16T10:54:47.037+01:00
With the additional minute-denominator in the timezone (yes - there are half-hour time zones on the globe ..)
What also is allowed is 2021-03-16T10:54:47.037Z
for "Zulu-time" which is equivalent to "+00:00"
Now we should assume that 90% of the receivers are implemented in I/O runtime and thus implemented in JS. So I think it's worth the effort fixing it.
You can argue, that this can easily be done with a regex in the client code...
BUT: Most of the time I received valid events with "Z" timezone.. and my code worked perfectly well.
Until now, when I saw these "incomplete" "+01" showing up in the queue..
and my perfectly working code stopped working
BTW: "+01:00" also is perfectly ISO-8601 compatible... so it should be safe to use that format instead.
Events produced by
aem
have the form:...
Unfortunately, the JavaScript methods Date.parse() or new Date() cannot parse Date-Strings like that one:
2021-03-16T10:54:47.037+01 //ERROR!!
(even though it's proper ISO-8601) The correct format is
2021-03-16T10:54:47.037+01:00
With the additional minute-denominator in the timezone (yes - there are half-hour time zones on the globe ..)
What also is allowed is
2021-03-16T10:54:47.037Z
for "Zulu-time" which is equivalent to "+00:00"Now we should assume that 90% of the receivers are implemented in I/O runtime and thus implemented in JS. So I think it's worth the effort fixing it.
You can argue, that this can easily be done with a regex in the client code... BUT: Most of the time I received valid events with "Z" timezone.. and my code worked perfectly well. Until now, when I saw these "incomplete" "+01" showing up in the queue.. and my perfectly working code stopped working
BTW: "+01:00" also is perfectly ISO-8601 compatible... so it should be safe to use that format instead.