It still might be reproducible by changing timezone and date accordingly. Though it can also depend on the date on the server.
- 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
- not a leap year
Apologies - yes version 5.9.3
Correct - if I close and then re-open WinSCP - then the files are displayed with correct 14:51 UTC-11 28th Feb 2017 date.
But remember my "reproducer" is highly synthetic - so I can appreciate that it is unfair to change the timezone underneath an already active WinSCP.
However, the original real world scenario was one instance of WinSCP in EST timezone displaying 28th Feb, and another instance in UTC timezone displaying 1st March.
The "UTC" user was uploading files into the FTP on 1st March saw good dates/outcome.
The "EST" user was downloading files from same FTP account using his WinSCP client back - and they noted that the dates were wrong.
The "EST" user restarted their client - same badness visible.
But 5 hours later then the badness was no longer visible to the EST client - because the WinSCP client in the EST timezone was now also on March 1st - far away from the leap year algorithm.
This won't be an issue again until next February - 2018 is another non-leap year.
And an end-user would need to be looking very closely (sort a directory by timestamp) to realize what is happening.
It is a minor issue in the grand scheme of life!
Correct - if I close and then re-open WinSCP - then the files are displayed with correct 14:51 UTC-11 28th Feb 2017 date.
But remember my "reproducer" is highly synthetic - so I can appreciate that it is unfair to change the timezone underneath an already active WinSCP.
However, the original real world scenario was one instance of WinSCP in EST timezone displaying 28th Feb, and another instance in UTC timezone displaying 1st March.
The "UTC" user was uploading files into the FTP on 1st March saw good dates/outcome.
The "EST" user was downloading files from same FTP account using his WinSCP client back - and they noted that the dates were wrong.
The "EST" user restarted their client - same badness visible.
But 5 hours later then the badness was no longer visible to the EST client - because the WinSCP client in the EST timezone was now also on March 1st - far away from the leap year algorithm.
This won't be an issue again until next February - 2018 is another non-leap year.
And an end-user would need to be looking very closely (sort a directory by timestamp) to realize what is happening.
It is a minor issue in the grand scheme of life!
- martin
Re: some problems displaying date when "not" a leap year
First, I assume you mean 5.9.3, not 3.9.3, right?
I would admit that WinSCP may not behave correctly, when the timezone settings changes, while WinSCP is running.
Can you reproduce similar problem, if you restart WinSCP after the timezone settings change?
I would admit that WinSCP may not behave correctly, when the timezone settings changes, while WinSCP is running.
Can you reproduce similar problem, if you restart WinSCP after the timezone settings change?
- not a leap year
some problems displaying date when "not" a leap year
Strange "non" leap year anomaly seen in WinSCP V3.9.3 build 7156
Discovered last night during real world scenario.
My colleague with WinSCP V3.9.3 client in UTC-5 timezone, while I was in UTC+0 timezone with same WinSCP V3.9.3 client on Win7.
Shortly after midnight for me - I saw sensible timestamps for freshly deposited files.
However, my colleague was seeing WinSCP "timetravel" back to 2016!
To my knowledge, my colleague was not tweaking timezone setting.
We were simply hitting "refresh" occasionally while anxiously waiting for a 3rd party to upload fresh files into our shared FTP.
I saw the fresh files in my directory listing - sorted by "changed" column.
He could not initially see the fresh files - because the fresh files were actually one year older - so they were at the other end of the directory listing!
I didn't have time to investigate last night - but had a few minutes this morning to experiment with a synthetic reproducer - using my PC alone:
My Win7 PC is in UTC+0 timezone, it is currently 10:08 UTC+0 1st March 2017.
I launch WinSCP V3.9.3 build 7156 and open FTP site with files having files with timestamp of 01:51 1st March 2017.
The files are displayed in WinSCP with correct/expected timestamp.
Next, from my PC taskbar, I change my timezone to UTC-11 (chosen so that I force the PC to "yesterday").
My Outlook pane refreshes automatically to take notice of the new timezone.
Within existing WinSCP session, I click the refresh icon for the remote directory.
The files in the remote directory now show a timestamp of 01:51 1st March 2016 - ie. the year went back, but other fields unchanged.
If I close and then re-open WinSCP - then the files are displayed with correct 14:51 UTC-11 28th Feb 2017 date.
Similar 1-year anomaly seen if my PC begins in UTC-11 timezone.
I launch WinSCP, open the FTP site, and the files have correct 14:51 UTC-11 28th Feb 2017 date.
I change timezone on my PC to UTC+0 (chosen so that I force the PC to "tomorrow").
My Outlook pane refreshes automatically to take notice of the new timezone.
Within existing WinSCP session, I click the refresh icon for the remote directory.
The files in the remote directory now show a timestamp of 14:51 28th Feb 2018 - ie. the year went forward, but other fields unchanged.
Weird!
Discovered last night during real world scenario.
My colleague with WinSCP V3.9.3 client in UTC-5 timezone, while I was in UTC+0 timezone with same WinSCP V3.9.3 client on Win7.
Shortly after midnight for me - I saw sensible timestamps for freshly deposited files.
However, my colleague was seeing WinSCP "timetravel" back to 2016!
To my knowledge, my colleague was not tweaking timezone setting.
We were simply hitting "refresh" occasionally while anxiously waiting for a 3rd party to upload fresh files into our shared FTP.
I saw the fresh files in my directory listing - sorted by "changed" column.
He could not initially see the fresh files - because the fresh files were actually one year older - so they were at the other end of the directory listing!
I didn't have time to investigate last night - but had a few minutes this morning to experiment with a synthetic reproducer - using my PC alone:
My Win7 PC is in UTC+0 timezone, it is currently 10:08 UTC+0 1st March 2017.
I launch WinSCP V3.9.3 build 7156 and open FTP site with files having files with timestamp of 01:51 1st March 2017.
The files are displayed in WinSCP with correct/expected timestamp.
Next, from my PC taskbar, I change my timezone to UTC-11 (chosen so that I force the PC to "yesterday").
My Outlook pane refreshes automatically to take notice of the new timezone.
Within existing WinSCP session, I click the refresh icon for the remote directory.
The files in the remote directory now show a timestamp of 01:51 1st March 2016 - ie. the year went back, but other fields unchanged.
If I close and then re-open WinSCP - then the files are displayed with correct 14:51 UTC-11 28th Feb 2017 date.
Similar 1-year anomaly seen if my PC begins in UTC-11 timezone.
I launch WinSCP, open the FTP site, and the files have correct 14:51 UTC-11 28th Feb 2017 date.
I change timezone on my PC to UTC+0 (chosen so that I force the PC to "tomorrow").
My Outlook pane refreshes automatically to take notice of the new timezone.
Within existing WinSCP session, I click the refresh icon for the remote directory.
The files in the remote directory now show a timestamp of 14:51 28th Feb 2018 - ie. the year went forward, but other fields unchanged.
Weird!