adobe / adobe/aio-lib-java

`aem` Date format not compatible with ECMA Script

Open
#103 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Java
Stars
7
Forks
22
PR merge metrics
No merged PRs in 30d

Description

Events produced by `aem` have the form:

```
{
"event_id": "2e38cbbe-4426-468c-b5ff-a8940e3210a6",
"event": {
"@id": "urn:oeid:aem:779885b1-f2fa-480d-b0c0-5a93619c5d29",
"@type": "xdmCreated",
"activitystreams:published": "2021-03-16T10:54:47.037+01",
"activitystreams:to": {
"@type": "xdmImsOrg",
"xdmImsOrg:id": "B28447B65D88A19F0A495C33@AdobeOrg"
},

```
...


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.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.