It should be obvious from my previous posts that I want to use/like WinSCP but what has happened is that I have realised that what I thought was it working correctly was in fact it doing things not quite correctly behind the scenes, viz the earlier versions were silently setting the time to 00:00:00, thus making them usually appear older, and so not listing them for download. When I updated to the latest version, the quirks/bugs appeared, because WinSCP was now reporting hh:mm:ss, but for some reason these were offset from correct time, or so it seems.
Or so it seems, because getting my head round these times is complicated, what with time zones and DST, and then add in Windows DST 'bug', and possible MLSD/UNIX/server bugs/errors/whatever.
My understanding is that UTC is a 'universal' (though we probably mean global) time ie it is at the same instant (same hh:mm:ss.000...) anywhere in the world. We then have the problem that when it is noon in Greenwich, it is not noon in New York, so we add (to the east of Greenwich, because noon is earlier)/subtract (to the west of Greenwich) from the UTC to get a local time. Sometimes we add an hour or two for DST. So file created at noon in Greenwich in winter (so its UTC time is 12:00:00.000) has, to make it age correctly in different time zones, to have its UTC time adjusted to local time. Consider what would happen if you looked at that Greenwich noon file in New York at 10am/2pm New York time without any time offset...
So it should be simple enough to correct a remote time zone offset back to UTC, and for - for example - file comparing, always have the file timestamp in UTC ie what the time was/is in Greenwich. If the time zone is five hours behind (Greenwich/New York, noon in the latter happens five hours later), then we need to subtract 5 to go from UTC to New York time, add 5 to go from New York time to UTC. So the noon file will be reported in New York as 07:00:00 - making the file appear younger than it does in Greenwhich (time shows as 12:00:00), even though it is the same file. To fix this, at some point we apply an offset, in this case we either *add* to the Newy York time to get UTC (better, correct option - the file is always seen as 12:00:00 UTC) or equally we could *subtract* from the UTC time to get New York time (bad, times quite literally all over the place).
Now the work I did yesterday which sadly went down the pan established there was something wrong with timestamp reporting somewhere. Frankly it's a;; so freakin' complicated there is a limit to how long I am prepared to spend messing about with it, but the one clear observable fact was that (this all on WinXP, so there's the DST 'bug' to consider as well) Filezilla and WinSCP reported different timestamps on the remote file, despite both apparently using MLSD to get the listing and timestamp. The only conclusion is that at least one if not both are wrong.
So, for the file in question (unicode.inc, which appears in WinSCP as listed for transfer as being newer when it isn't, it's the same file):
Local timestamp in Windows Explorer (Props to get ss), FileZilla and WinSCP local pane: 05:09:08
FileZilla Remote (server) pane, no offset dialled in: 10:09:08
WinSCP GUI Remote (server) pane: 11:09:08
WinSCP Log entry for the listing: 09:09:08
The actual log entries (there are two for each file) for unicode.inc are:
. 2016-10-14 08:24:55.640 type=file;size=18180;modify=20150707090908;
. 2016-10-14 08:24:55.640 unicode.inc;-;18180;2015-07-07T09:09:08.000Z; (Z and .000 ie ms = UTC?)
So there's at least some time-warping going on. The first oddity is why are the New York (remote, to the west, so *behind* in time) times *ahead* in time? Crack that one, mate, and you may just be a Time Lord yet! The next oddity is why are FileZilla and WinSCP (both, remember, using MLSD, confirmed in the respective logs) showing different times??? And why is WinSCP showing different times in the log, and in the GUI???
On balance , it seems WinSCP has got its knickers in more of a twist than FileZilla. FileZilla shows a credible 5 hour offset (because that is, so far as we know, the real world offset), whereas WinSCP has two offsets, so both can't be right, and quite possibly both are wrong (4 and 6 hous offsets when it should be 5 hours).
Clearly something is wrong somewhere. It would be nice to have the code do it all correctly in the first place, but clearly it isn't - the times are all over the place. Sometimes it is easier just to dial in the correction manually. FileZilla allows this, but - for reasons I cannot really understand - you are reluctant to let WinSCP achieve this.
By the way, the time offset option is there in WinSCP (it can even be set, eg by changing to another mode then back to FTP), but greyed out - you have it appears deliberately turned it off. It even gets logged in the log file, but not used in plain FTP mode. This apparent 'I did it my way' approach is incidentally also apparent in the password visible/invisible fandango that appears from time to time here on the forum. You don't have to like your punters, but when they point our real problems, and propose possible solutions, it might be helpful to listen.
PS I really dislike this forum implementation. Tight attachment number/size limits, logs you out too early etc. Confirmation codes when there shouldn't be. Not a friendly environment at all...
Reply with quote