Timestamp is set only after the transfer finishes. It's not even technically possible to do it earlier. If you have a different experience, please attach a complete session log file.

When synchronizing locally WinSCP creates the local file with the same timestamp as on the server. This means if WinSCP process is killed (In my case by SSIS/SQL Agent after a timeout) then when run again WinSCP skips the file the second time.

This is even true when -criteria=either is set in an attempt to use file size to retry failed attempts. It looks like time trumps size, even for local sync.

open ftp://anonymous:anonymous@wireless.fcc.gov
cd /pub/uls/daily

# does not retry interrupted downloads, even though local size is different, time trumps size even for -criteria=either
synchronize local -criteria=either -filemask=l_lb_*

One possible fix: set the timestamp on the file when the download is complete. Let it default to 'now', and set to server time when done. This way interrupted/killed sync operations would automatically restart on 2nd attempt. I think this only makes sense for local/remote, not for 'both' where newest file wins.

P.S. It's possible to force size sync by running two sync commands, but it is awkward when file mask is complex.
Example:

# this is only here to force re-download if previous download was killed
synchronize local -criteria=size -filemask=l_lb_*;l_lc_*;l_lp_*;l_mw_*;l_pg_*
# do normal sync - by timestamp
synchronize local -criteria=time -filemask=l_lb_*;l_lc_*;l_lp_*;l_mw_*;l_pg_*