So the use case for using 1800-01-01in our case was, to some extent, arbitrary. Business needed some arbitrary, very old date for some data. We got around the issue by choosing 1900-01-01 instead.
The problem of course is valid. One solution could be to pass date in milliseconds (i.e. number of milliseconds since January 1, 1970, 00:00:00 GMT) Salesforce seems to accept that. Need to get some verification on that though. Here's the relevant Camel SaleForce component code https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/JsonRestProcessor.java#L59 <https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-component/src/main/java/org/apache/camel/component/salesforce/internal/processor/JsonRestProcessor.java#L59> replacing this.objectMapper.configure(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, false); with this.objectMapper.configure(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, true); results in milliseconds. Not sure of any other other side effects of this. -- View this message in context: http://camel.465427.n5.nabble.com/camel-salesforce-component-date-time-issue-tp5784399p5784463.html Sent from the Camel - Users mailing list archive at Nabble.com.
