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

Daniel Stieglitz edited comment on NIFI-14620 at 6/6/25 4:03 PM:
-----------------------------------------------------------------

[~fube1] 

In NIFI 1.x toDate under the hood used java.text.SimpleDateFormat to create the 
java.util.Date object while in NIFI 2.x toDate now uses 
java.time.format.DateTimeFormatter to create a java.time.Instant object and 
then create a java.util.Date object from that.
When using java.text.SimpleDateFormat the timezone information was preserved 
hence when java.util.Date toString was called you were able to see the various 
time zones you had set. java.time.Instant does not have timezone information 
hence the java.util.Date toString falls back to using the locale's where its 
run timezone. This is why you consistently see Sun Jun 01 00:00:00 CEST 2025 no 
matter what timezone you set.

In order to get the expected results in NIFI 2.x, you must chain three NIFI 
expressions together and use the syntax from java.time.format.DateTimeFormatter 
to get
the timestamp you desire. Please see table below for the time zones you 
specified
||Expression||Result||
|${date:toDate('yyyyMMdd','UTC'):toNumber():formatInstant('EEE MMM dd HH:mm:ss 
zzz yyyy', 'UTC')}|Sun Jun 01 00:00:00 UTC 2025|
|${date:toDate('yyyyMMdd','Europe/Kiev'):toNumber():formatInstant('EEE MMM dd 
HH:mm:ss zzz yyyy', 'Europe/Kiev')}|Sun Jun 01 03:00:00 EEST 2025|
|${date:toDate('yyyyMMdd','America/Detroit'):toNumber():formatInstant('EEE MMM 
dd HH:mm:ss zzz yyyy', 'America/Detroit')}|Sat May 31 20:00:00 EDT 2025|


was (Author: JIRAUSER294662):
[~fube1] 

In NIFI 1.x toDate under the hood used java.text.SimpleDateFormat to create the 
java.util.Date object while in NIFI 2.x toDate now uses 
java.time.format.DateTimeFormatter to create a java.time.Instant object and 
then create a java.util.Date object from that.
When using java.text.SimpleDateFormat the timezone information was preserved 
hence when java.util.Date toString was called you were able to see the various 
time zones you had set. java.time.Instant does not have timezone information 
hence the java.util.Date toString falls back to using the locale's where its 
run timezone. This is why you consistently see Sun Jun 01 00:00:00 CEST 2025 no 
matter what timezone you set.

In order to get the expected results you must chain three NIFI expressions 
together and use the syntax from java.time.format.DateTimeFormatter to get
the timestamp you desire. Please see table below for the time zones you 
specified
||Expression||Result||
|${date:toDate('yyyyMMdd','UTC'):toNumber():formatInstant('EEE MMM dd HH:mm:ss 
zzz yyyy', 'UTC')}|Sun Jun 01 00:00:00 UTC 2025|
|${date:toDate('yyyyMMdd','Europe/Kiev'):toNumber():formatInstant('EEE MMM dd 
HH:mm:ss zzz yyyy', 'Europe/Kiev')}|Sun Jun 01 03:00:00 EEST 2025|
|${date:toDate('yyyyMMdd','America/Detroit'):toNumber():formatInstant('EEE MMM 
dd HH:mm:ss zzz yyyy', 'America/Detroit')}|Sat May 31 20:00:00 EDT 2025|

> EL toDate() always uses local timezone
> --------------------------------------
>
>                 Key: NIFI-14620
>                 URL: https://issues.apache.org/jira/browse/NIFI-14620
>             Project: Apache NiFi
>          Issue Type: Bug
>          Components: Core Framework
>    Affects Versions: 2.4.0
>         Environment: OS: RedHat 9.5
>            Reporter: Beat Fuellemann
>            Priority: Major
>
> I use a parameter date "20250601". Nifi is running in CEST timezone.
> Now I need to generate a date in UTC based on the parameter "date".
> If I use UpdateAttribute Processor with 
> ${date:toDate(''yyyyMMdd,'UTC')}, it generates the timestamp "Sun Jun 01 
> 00:00:00 CEST 2025". I would expect "Sun Jun 01 *02:00:00* CEST 2025".
> I also already tested it with timezone "Europe/Kiev" or "America/Detroit", I 
> always get "Sun Jun 01 00:00:00 CEST 2025".
> It looks, that this Nifi expression Language method "toDate" always uses the 
> local timezone.
> In release 1.23.2 it was working fine.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to