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)