Weird behavior of remote timestamps

Dear WinSCP experts,

i have some trouble with timestamps.

My setup ist winscp 5.11.3 build 7995 on windows server 2016 build 1607 and corresponding FTP Server ist vsftpd 3.0.2 on CentOS7, both in Germany, so timezone is GMT+1, and i use FTPS protocol in this context.

WinSCP shows files in the GUI which are already on the FTP Server and which have last modification time (LMT) in december (for example) with correct timestamps (the LMT in WinSCP in the right pane is the same time as with "ls -al" in the linux shell). But files on the FTP Server with LMT in summer 2017 are shown in WinSCP with an offset of -1 hour compared to linux shell.
My origin was using default session properties (MLSD=AUTO), then, because vsftpd has no MLSD feature, i fiddled with MLSD=off and some timezonedifferences, but got only a time shift for all files and on top the same -1h offset for files last modified while DST.
In contrast, FileZilla shows all timestamps consistent as with "ls -al".
I do *not* set vsftpd config option use_localtime=yes, so vsftpd uses UTC timestamps internally, which is the preferred setup. use_localtime=yes is no choice because it would break other dependencies.

I thoroughly read the FAQ about timestamps but i found no reason for this behavior.

Many thanks for a useful explanation.

Roman

Please attach a full session log file showing the problem (using the latest version of WinSCP).

Hi Martin,

see attached logfile an screenshots.
Thank You for your assistance.

Roman

Hi Martin,
some words to make things easier ...
The file "Neues Textdokument.txt" was created some days ago in this week and shows the correct date and time (beside the missing seconds) in the right WinSCP pane. The other two files are from september, which was DST. They both have correct date but wrong time (IMHO), shifted one hour in the past, as you can compare with the screenshot from the linux shell.
All remote files were previously uploaded by WinSCP from the local system. The source files are shown in the left pane. As you can see "Neues Textdokument.txt" has the same date and time as the remote copy, but timestamps of the other both files differs.

New session log from WinSCP Version 5.13 (Build 8172) attached, same results with this version.

Hi Martin,
seems you are back from vacation.
Do we have any chance to handle the the time offset described in my previous posts?
Thank you
Roman

As you can see yourself in the log, it's the FTP server that adjusts timestamps of files created in DST by one hour:


Compare with the timestamps you can see in the shell.

As you seem to have a shell access, I wonder why don't you use SFTP, instead of FTP?

Hi Martin,
thank you for your response, i needed some days to think about.
Maybe we have different point of view, but the logfile shows timestamps in UTC, which are absolutely correct. My expectation was either timestamps were represented in realtime (localtime) in the client (WinSCP) or completely in UTC, which would be nice too. But what WinSCP does is simply to add one hour offset to all files, which is wrong in my opinion. To show realtime (localtime) times, WinSCP has to add one hour to "winter"-files and two hours to DST-files, if we refer to my local timezone. FileZilla in contrast makes the correct calculation as you can see in the screenshot i attached for illustration.
Thx, Roman

Times as shown by LIST are usually shown in a local time of the server. So usually they are already adjusted for DST in server's timezone. So WinSCP displays them as they are, just adjusted for (detected) timezone difference.
That works for most servers. It may not work for all (such as yours).
FileZilla has a different logic, which happens to work for your server, but will fail for others (unless it has some smart logic to autodetect what logic to use, what I do not think it has).
There would have to be a configuration option to switch between the approaches. Actually WinSCP has that ("Daylight saving time" section), but it's currently implemented for SFTP protocol only.
The primary problem is that your FTP server is obsolete. Modern FTP servers support MLSD command, which is required to return times in UTC. Then, there are no such problems. Your server does not support MLSD.

martin wrote:

The primary problem is that your FTP server is obsolete. Modern FTP servers support MLSD command, which is required to return times in UTC. Then, there are no such problems. Your server does not support MLSD.

vsftp does not supprt MLSD, that is a well-known an often criticized fact. But it is not obsolete. vsftp is very popular and it is the default FTP Server in current RHEL7 distribution.

I think a solution for this situation isn't really difficult. Wouldn't it be possible to treat the LIST result the same way like MLSD? Everything would be fine.
Do i have a chance that you will find a simple solution or a workaround? :-)
Thanks in advance,
Roman

An other question:

martin wrote:

Times as shown by LIST are usually shown in a local time of the server. So usually they are already adjusted for DST in server's timezone. So WinSCP displays them as they are, just adjusted for (detected) timezone difference.

If WinSCP treats LIST result as local time, why does it add one hour to all this timestamps?

If theoretical my vsftp server delivers already to local time adjusted values by LIST command, it makes much more confusion to add any offset at all.

Because WinSCP detected 1 hour difference between the server and the client:

. 2018-02-25 13:29:42.815 Timezone difference of -1 detected using file /mnt/FTPPOOL/praxislorenz/backup/ftptest/NeuesTextdokument.txt (Listing: 2018-02-22T11:33:00.000Z, UTF: 2018-02-22T12:33:00.000Z)

You can turn off the detection in session settings.