You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Peter Turcsanyi (Jira)" <ji...@apache.org> on 2021/01/15 15:56:00 UTC
[jira] [Updated] (NIFI-8145) ListFTP is not aware of the server's
time zone
[ https://issues.apache.org/jira/browse/NIFI-8145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Turcsanyi updated NIFI-8145:
----------------------------------
Description:
FTP servers sends the last modification time of the files in UTC or in their local timezone but NiFi (or more precisely the underlying commons-net FTPClient) interprets it in its local time zone by default.
For example:
- FTP server is located in EST, the file mod time is "Jan 14 15:34"
- the server sends it in UTC as "20210114203400" (MDTM) or "Jan 14 20:34" (LIST)
- NiFi interprets it in local time zone and sets file.lastModifiedTime attribute on the FF like "2021-01-14T20:34:00+0100" (if running in GMT+1) or "2021-01-14T20:34:00+1100" (if running in GMT+11), they should be "2021-01-14T21:34:00+0100" and "2021-01-15T07:34:00+1100" respectively
It does not cause any problem (beyond the incorrect attribute value) in Timestamp Tracing strategy because every timestamps will be shifted with the same amount but it may be a problem in case of the new Time Window strategy (being implemented in NIFI-8081).
Add a new property to specify the server's time zone by the user (it is not possible to get it back from the server). The property should be optional and the previous behaviour should be provided when not specified.
was:
FTP servers sends the last modification time of the files in UTC or in their local timezone but NiFi (or more precisely the underlying commons-net FTPClient) interprets it in the local time zone if NiFi by default.
For example:
- FTP server is located in EST, the file mod time is "Jan 14 15:34"
- the server sends it in UTC as "20210114203400" (MDTM) or "Jan 14 20:34" (LIST)
- NiFi interprets it in local time zone and sets file.lastModifiedTime attribute on the FF like "2021-01-14T20:34:00+0100" (if running in GMT+1) or "2021-01-14T20:34:00+1100" (if running in GMT+11), they should be "2021-01-14T21:34:00+0100" and "2021-01-15T07:34:00+1100" respectively
It does not cause any problem (beyond the incorrect attribute value) in Timestamp Tracing strategy because every timestamps will be shifted with the same amount but it may be a problem in case of the new Time Window strategy (being implemented in NIFI-8081).
Add a new property to specify the server's time zone by the user (it is not possible to get it back from the server). The property should be optional and the previous behaviour should be provided when not specified.
> ListFTP is not aware of the server's time zone
> ----------------------------------------------
>
> Key: NIFI-8145
> URL: https://issues.apache.org/jira/browse/NIFI-8145
> Project: Apache NiFi
> Issue Type: Improvement
> Reporter: Peter Turcsanyi
> Priority: Major
>
> FTP servers sends the last modification time of the files in UTC or in their local timezone but NiFi (or more precisely the underlying commons-net FTPClient) interprets it in its local time zone by default.
> For example:
> - FTP server is located in EST, the file mod time is "Jan 14 15:34"
> - the server sends it in UTC as "20210114203400" (MDTM) or "Jan 14 20:34" (LIST)
> - NiFi interprets it in local time zone and sets file.lastModifiedTime attribute on the FF like "2021-01-14T20:34:00+0100" (if running in GMT+1) or "2021-01-14T20:34:00+1100" (if running in GMT+11), they should be "2021-01-14T21:34:00+0100" and "2021-01-15T07:34:00+1100" respectively
> It does not cause any problem (beyond the incorrect attribute value) in Timestamp Tracing strategy because every timestamps will be shifted with the same amount but it may be a problem in case of the new Time Window strategy (being implemented in NIFI-8081).
> Add a new property to specify the server's time zone by the user (it is not possible to get it back from the server). The property should be optional and the previous behaviour should be provided when not specified.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)