[ 
https://issues.apache.org/jira/browse/NIFI-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17979870#comment-17979870
 ] 

super dachuan commented on NIFI-14572:
--------------------------------------

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 28 hours I 
observed earlier, this could still be the root cause of the issue — the 28-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, Core UI
>    Affects Versions: 2.4.0
>            Reporter: super dachuan
>            Priority: Major
>         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)

Reply via email to