adobe / aio-lib-java

Adobe I/O - Java SDK
https://opensource.adobe.com/aio-lib-java/
Apache License 2.0
6 stars 18 forks source link

`aem` Date format not compatible with ECMA Script #103

Open francoisledroff opened 2 years ago

francoisledroff commented 2 years ago

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.

sangeetha5491 commented 1 year ago

Can you please add steps to reproduce this error