Timezone offset determination logic for FTP?
How is the timezone offset being determined? From what I understand for FTP when using the
Initially it gives a warning:
and then once a file is found it will use that to determine the offset:
I am using the .NET WinSCP library to monitor certain folders on a FTP. One of the criteria I am monitoring is the file age. Usually the file timestamp is correct, however over the weekend I suddenly had a time difference of 5 hours.
During the weekend the monitoring service is shutdown during a specific time window. Then at some point it is started again. It seems that after the restart of the service, the monitored folder contained some files which were there for a few hours, waiting to be picked up.
I am wondering, when WinSCP accesses a folder for the first time of the lifecycle of a session and it contains files which are aging, if there could be a disconnect in the determination of the time zone offset. Unfortunately I don't have session logs to confirm that this is what actually happened. I will see if I can do some tests to proof this.
LIST to list directory content, it will use one of the files within the folder to determine the offset. This is also visible from the logs.
Initially it gives a warning:
. 2024-12-02 13:28:23.420 Detecting timezone difference... . 2024-12-02 13:28:23.420 Found no file to use for detecting timezone difference . 2024-12-02 13:28:23.420 Warning: Timezone difference was not detected yet, timestamps may be incorrect
. 2024-12-02 13:31:03.347 Detecting timezone difference... . 2024-12-02 13:31:03.347 Retrieving file information... > 2024-12-02 13:31:03.348 PWD < 2024-12-02 13:31:03.493 257 "[redacted]" is current directory. > 2024-12-02 13:31:03.493 CWD [redacted]/20241202.564_20241202073053816 < 2024-12-02 13:31:03.640 550 The filename, directory name, or volume label syntax is incorrect. > 2024-12-02 13:31:03.640 TYPE I < 2024-12-02 13:31:03.785 200 Type set to I. > 2024-12-02 13:31:03.786 SIZE /[redacted]/20241202.564_20241202073053816 < 2024-12-02 13:31:03.931 213 6384 > 2024-12-02 13:31:03.931 MDTM [redacted]/20241202.564_20241202073053816 < 2024-12-02 13:31:04.078 213 20241202123054 . 2024-12-02 13:31:04.078 Retrieving file information successful . 2024-12-02 13:31:04.078 Timezone difference of -6 detected using file [redacted]/20241202.564_20241202073053816 (Listing: 2024-12-02T06:30:00.000Z, UTC: 2024-12-02T12:30:00.000Z)
During the weekend the monitoring service is shutdown during a specific time window. Then at some point it is started again. It seems that after the restart of the service, the monitored folder contained some files which were there for a few hours, waiting to be picked up.
I am wondering, when WinSCP accesses a folder for the first time of the lifecycle of a session and it contains files which are aging, if there could be a disconnect in the determination of the time zone offset. Unfortunately I don't have session logs to confirm that this is what actually happened. I will see if I can do some tests to proof this.
