Re: additional info for changed times off by 1 hours
For explanation of WinSCP behaviour see documentation. For feedback please follow to this topic.
- martin
Post a reply
Before posting, please read how to report bug or request support effectively.
Bug reports without an attached log file are usually useless.
Topic review
- Norm
Re: additional info for changed times off by 1 hours
"Goodnews",
When you did your test, where you in or out of DST (Daylight Savings Time, or the "summer season")? If you try repeating the test in the opposite "season", you might find the results change in even other ways.
When I advanced my clock to EST ("winter season"), the displayed times were correct!
This behaviour seems consistent with the code I posted in https://winscp.net/forum/viewtopic.php?t=2503 which showed the file timestamp being adjusted by the _current_ DST offset. In other words, I suspect people will see more 1 hr offset problems during the "summer" season. Also, perhaps, those that somehow adjusted things to make the offset go away might be in for a surprise when clocks change for the "winter" season. It might mean, for example, that all files transferred during one season will suddenly look newer or older in the other season and cause some unnecessary transfers with the Synchronize function.
Time...not only do I not have enough of it, but it is sooo deceptively simple. ;-)
- Norm
When you did your test, where you in or out of DST (Daylight Savings Time, or the "summer season")? If you try repeating the test in the opposite "season", you might find the results change in even other ways.
Clarification, I had one file from the "winter season" (the EST file) and one from the "summer season" (the DST file) and in "Server adjusts DST" mode, the DST file is still listed as 1 hr advanced, and the EST file is listed as 2 (!) hrs advanced. This is while I am in DST ("summer season") locally.In the case of the reporter "Norm", I suspect that the date of the examined files was in the winter season and he/she couldn't solve the problem.
When I advanced my clock to EST ("winter season"), the displayed times were correct!
This behaviour seems consistent with the code I posted in https://winscp.net/forum/viewtopic.php?t=2503 which showed the file timestamp being adjusted by the _current_ DST offset. In other words, I suspect people will see more 1 hr offset problems during the "summer" season. Also, perhaps, those that somehow adjusted things to make the offset go away might be in for a surprise when clocks change for the "winter" season. It might mean, for example, that all files transferred during one season will suddenly look newer or older in the other season and cause some unnecessary transfers with the Synchronize function.
Time...not only do I not have enough of it, but it is sooo deceptively simple. ;-)
- Norm
- goodnews
additional info for changed times off by 1 hours
As pointed out by other peoples before, WinSCP (ver 3.7.6) seems to have a problem in extracting the correct time of files on the remote machine; the time is changed to be 1 hour later than correct one.
Some peoples informed that they resolved this problem by setting "Server adjusts DST", while some peoples couldn't.
I tried several methods and found that there exists a strange correlation between the (changed) time and the date of files. Let me explain it. For the sake of your understanding, I want to tell that the Windows XP has been used as a local machine and the SuSE Linux as a remote machine (UTC used). The time zone of both machines was set to Europe/Switzerland.
First, by setting "Server works in UTC time (adjust DST locally)", the time of files in the remote machine is always 1 hour later than correct one.
Second, by setting "Server adjusts DST", the time of files made in the "summer" season is extracted correctly, while the files made in the "winter" season show wrong time (+1 hour). In the case of the reporter "Norm", I suspect that the date of the examined files was in the winter season and he/she couldn't solve the problem.
I think it explains why some people could resolve this problem and others couldn't. It depends on the date of files they tried to synchronize!
Of course, I cannot explain why it happens. It's up to developers.^^ I wish this problem will be resolved as soon as possible.
Some peoples informed that they resolved this problem by setting "Server adjusts DST", while some peoples couldn't.
I tried several methods and found that there exists a strange correlation between the (changed) time and the date of files. Let me explain it. For the sake of your understanding, I want to tell that the Windows XP has been used as a local machine and the SuSE Linux as a remote machine (UTC used). The time zone of both machines was set to Europe/Switzerland.
First, by setting "Server works in UTC time (adjust DST locally)", the time of files in the remote machine is always 1 hour later than correct one.
Second, by setting "Server adjusts DST", the time of files made in the "summer" season is extracted correctly, while the files made in the "winter" season show wrong time (+1 hour). In the case of the reporter "Norm", I suspect that the date of the examined files was in the winter season and he/she couldn't solve the problem.
I think it explains why some people could resolve this problem and others couldn't. It depends on the date of files they tried to synchronize!
Of course, I cannot explain why it happens. It's up to developers.^^ I wish this problem will be resolved as soon as possible.