[
https://issues.apache.org/jira/browse/NIFI-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17979870#comment-17979870
]
super dachuan edited comment on NIFI-14572 at 8/6/25 7:59 AM:
--------------------------------------------------------------
I have confirmed that this is not a frontend request issue. The problem comes
from the backend. In the Provenance response, the {{request}} section shows a
different date/time than what was submitted.
This issue may be related to the
{{org.apache.nifi.web.api.dto.util.DateTimeAdapter}} class. In NiFi 2.x, the
{{unmarshal}} method was changed to use {{{}java.time{}}}, but the behavior is
different from NiFi 1.x.
{code:java}
@Override
public Date unmarshal(String date) throws Exception {
final ZonedDateTime zonedDateTime = ZonedDateTime.parse(date,
DATE_TIME_FORMATTER);
return Date.from(zonedDateTime.toInstant());
} {code}
I reproduced the problem locally by copying the {{unmarshal}} code from NiFi 1
and NiFi 2. I used the same input string, and the two versions returned
different timestamps.
Here is the test code:
{code:java}
private static final String DEFAULT_DATE_TIME_FORMAT = "MM/dd/yyyy HH:mm:ss z";
private static final DateTimeFormatter DATE_TIME_FORMATTER =
DateTimeFormatter.ofPattern(DEFAULT_DATE_TIME_FORMAT);
public static void main(String[] args) throws Exception {
String dateStr = "06/17/2025 00:00:00 CST";
Date dateFromNiFi1 = unmarshalNiFi1(dateStr);
Date dateFromNiFi2 = unmarshalNiFi2(dateStr);
System.out.println("NiFi 1 unmarshal output: " + dateFromNiFi1.getTime());
System.out.println("NiFi 2 unmarshal output: " + dateFromNiFi2.getTime());
}
public static Date unmarshalNiFi1(String date) throws Exception {
final SimpleDateFormat parser = new
SimpleDateFormat(DEFAULT_DATE_TIME_FORMAT, Locale.US);
parser.setTimeZone(TimeZone.getDefault());
return parser.parse(date);
}
public static Date unmarshalNiFi2(String date) throws Exception {
final ZonedDateTime zonedDateTime = ZonedDateTime.parse(date,
DATE_TIME_FORMATTER);
return Date.from(zonedDateTime.toInstant());
} {code}
And here is the output:
{code:java}
NiFi 1 unmarshal output: 1750089600000
NiFi 2 unmarshal output: 1750136400000{code}
This shows that the date/time parsing works differently in NiFi 2.x. Although
the time difference between the two versions is not exactly the 52 hours I
observed earlier, this could still be the root cause of the issue — the 52-hour
offset might have resulted from multiple conversions.
was (Author: super_dachuan):
I have confirmed that this is not a frontend request issue. The problem comes
from the backend. In the Provenance response, the {{request}} section shows a
different date/time than what was submitted.
This issue may be related to the
{{org.apache.nifi.web.api.dto.util.DateTimeAdapter}} class. In NiFi 2.x, the
{{unmarshal}} method was changed to use {{{}java.time{}}}, but the behavior is
different from NiFi 1.x.
{code:java}
@Override
public Date unmarshal(String date) throws Exception {
final ZonedDateTime zonedDateTime = ZonedDateTime.parse(date,
DATE_TIME_FORMATTER);
return Date.from(zonedDateTime.toInstant());
} {code}
I reproduced the problem locally by copying the {{unmarshal}} code from NiFi 1
and NiFi 2. I used the same input string, and the two versions returned
different timestamps.
Here is the test code:
{code:java}
private static final String DEFAULT_DATE_TIME_FORMAT = "MM/dd/yyyy HH:mm:ss z";
private static final DateTimeFormatter DATE_TIME_FORMATTER =
DateTimeFormatter.ofPattern(DEFAULT_DATE_TIME_FORMAT, Locale.US);
public static void main(String[] args) throws Exception {
String dateStr = "06/17/2025 00:00:00 CST";
Date dateFromNiFi1 = unmarshalNiFi1(dateStr);
Date dateFromNiFi2 = unmarshalNiFi2(dateStr);
System.out.println("NiFi 1 unmarshal output: " + dateFromNiFi1.getTime());
System.out.println("NiFi 2 unmarshal output: " + dateFromNiFi2.getTime());
}
public static Date unmarshalNiFi1(String date) throws Exception {
final SimpleDateFormat parser = new
SimpleDateFormat(DEFAULT_DATE_TIME_FORMAT, Locale.US);
parser.setTimeZone(TimeZone.getDefault());
return parser.parse(date);
}
public static Date unmarshalNiFi2(String date) throws Exception {
final ZonedDateTime zonedDateTime = ZonedDateTime.parse(date,
DATE_TIME_FORMATTER);
return Date.from(zonedDateTime.toInstant());
} {code}
And here is the output:
{code:java}
NiFi 1 unmarshal output: 1750089600000
NiFi 2 unmarshal output: 1750136400000{code}
This shows that the date/time parsing works differently in NiFi 2.x. Although
the time difference between the two versions is not exactly the 52 hours I
observed earlier, this could still be the root cause of the issue — the 52-hour
offset might have resulted from multiple conversions.
> Provenance search request date/time is inconsistent with the date/time shown
> in the UI
> --------------------------------------------------------------------------------------
>
> Key: NIFI-14572
> URL: https://issues.apache.org/jira/browse/NIFI-14572
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Affects Versions: 2.4.0
> Reporter: super dachuan
> Priority: Major
> Labels: dateformat, datetime, provenance
> Attachments: 2025-05-16_16-42-12.png, 2025-05-16_16-47-46.png
>
>
> When using the Provenance UI to perform a search — for example, entering the
> date/time range *5/16/2025 00:00:00 - 5/16/2025 23:59:59 (CST)* — and
> clicking the *Search* button, the actual provenance request generated
> contains an incorrect date/time range:
> {{{}startDate: "05/18/2025 04:00:00 CST"{}}},
> {{{}endDate: "05/19/2025 03:59:59 CST"{}}}.
> As a result, the search returns incorrect results.
> Please refer to the attached screenshot for both the UI input and the
> resulting request.
> We encountered this issue in version 2.4.0, but it is unclear whether the
> problem also exists in earlier 2.x versions.
>
> Update:
> I also tested a deployment without any explicit timezone configuration (i.e.,
> using the default UTC timezone), and it worked as expected. However, after
> setting the server timezone to my local timezone ({*}Asia/Shanghai{*}), the
> issue described above started to occur.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
