You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Claus Ibsen (Jira)" <ji...@apache.org> on 2022/09/07 12:48:00 UTC
[jira] [Resolved] (CAMEL-18473) Knative component : CloudEvents have wrong time format
[ https://issues.apache.org/jira/browse/CAMEL-18473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen resolved CAMEL-18473.
---------------------------------
Resolution: Fixed
> Knative component : CloudEvents have wrong time format
> ------------------------------------------------------
>
> Key: CAMEL-18473
> URL: https://issues.apache.org/jira/browse/CAMEL-18473
> Project: Camel
> Issue Type: Bug
> Components: camel-knative
> Affects Versions: 3.18.1
> Reporter: Zineb Bendhiba
> Assignee: Zineb Bendhiba
> Priority: Major
> Fix For: 3.18.3, 3.19.0
>
>
>
> When trying camel knative component with InMemory channels, we can't see the bug because this one doesn't validate the event.
> Outside of this use case when the event is validated on knative, it seems that the time has wrong DateFormat.
> For instance, if using the component with a broker, we can't produce an event with camel-knative, and this is the log in knative environment :
>
> {code:java}
> {"level":"warn","ts":"2022-09-06T14:35:10.587Z","logger":"mt_broker_ingress","caller":"ingress/ingress_handler.go:137","msg":"failed to extract event from request","error":"invalid value for time: \"22022-08-31T12:00:33.253+02:00\""} {code}
> This is the valid DateFormat, according to [CloudEvents spec|[https://github.com/cloudevents/spec]]
>
> {code:java}
> "time" : "2018-04-05T17:31:00Z", {code}
> This corresponds in the Java DateTimeFormatter class to [#ISO_INSTANT].
> However, in camel-knative producer uses [#ISO_OFFSET_DATE_TIME]
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)