@prova    Based on timestamp shared, the source is RFC3164 syslog messages in which the timestamp does not include a year. The SyslogReader supports both RFC3164 and RFC5424 syslog messages, but uses a generic syslog schema applied against the source data: { "type" : "record", "name" : "nifiRecord", "namespace" : "org.apache.nifi", "fields" : [ { "name" : "priority", "type" : [ "null", "string" ] }, { "name" : "severity", "type" : [ "null", "string" ] }, { "name" : "facility", "type" : [ "null", "string" ] }, { "name" : "version", "type" : [ "null", "string" ] }, { "name" : "timestamp", "type" : [ "null", "string" ] }, { "name" : "hostname", "type" : [ "null", "string" ] }, { "name" : "body", "type" : [ "null", "string" ] } ] } You can see that timestamp is treated as a string. When it comes to reformatting the customer is looking for, where is NiFi expected to extract the year from since int is not in the syslog message? Since schema treats the timestamp as a string, it can't be treated like a timestamp type within the syslog for reformatting.This is possible with RFC5424 formatted source syslog messages. This is not to say that you could not manipulate this date string via some downstream processor, but would still need to figure out where you are going to get the year from.  NiFi can't assume that RFC3164 formatted syslog message was produced in same year that NiFi is parsing it.  This becomes hard to handle evening via some downstream processor at end of year where NiFi servers may already be in 2022 for example but received RFC3164 syslog messages were produced in 2021. RFC3164 was absolute when RFC5424 was introduced.  RFC3164 syslog messages are produced by older systems and the options here are limited. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt ... View more