Short answer
When a server does not support UTC-based timestamps (MFMT/MLST with UTC), FileZilla interprets the modification times it receives from LIST/MLSD using the client machine's local time zone. There is no per-site time zone offset setting in Site Manager — in any current FileZilla 3.x release, this is not a supported feature. The practical fix is to enable timestamp preservation on upload (which uses MFMT when the server supports it) and to treat displayed remote times as approximate when the server lacks UTC support.
How the offset is actually determined
FileZilla's behavior depends on what the server advertises in its FEAT response:
- Server supports MFMT (RFC 3659): FileZilla sends
MFMT YYYYMMDDHHMMSS path with the time in UTC after upload, so the remote timestamp matches the local file regardless of either side's time zone. This is the "Preserve timestamps of transferred files" option under Edit → Settings → Transfers.
- Server supports MLSD/MLST with UTC facts: Directory listings carry a
modify= fact in UTC, which FileZilla converts to local time for display. No drift occurs.
- Legacy LIST only: The server returns times in its own local time with no offset information. FileZilla has nothing to convert against, so it assumes the timestamps are in the client's local time zone. If the server is in another zone, every displayed time is off by the difference — this is the drift you are seeing.
So the "offset" is not calculated at all in the legacy case; it is implicitly zero, which is exactly why drift appears.
Is there a manual per-site offset?
No. Site Manager has no time zone field, and this is not exposed as a documented setting. Editing sitemanager.xml or filezilla.xml by hand to inject an offset is unsupported and may be ignored or break on upgrade — I would not recommend relying on it. Your realistic options are:
- Prefer servers with MFMT/MLSD support. Most modern servers (vsftpd, ProFTPD, Pure-FTPd) support both; if you control the server, enabling these is the clean fix.
- Use SFTP instead of FTP where possible. SFTP (SSH File Transfer Protocol) carries timestamps as UTC epoch values, eliminating the ambiguity entirely.
- Account for the offset mentally or in tooling. If the server is a fixed known offset (e.g., always UTC+5:30), note it in the site name/comments and compare against server time, not local time.
How to verify what your server does
Open FileZilla's message log (set debug verbosity via Edit → Settings → Debug) and connect. Look at the FEAT response:
Response: 211-Features:
Response: MFMT
Response: MLST modify*;size*;type*;
Response: 211 End
If MFMT and MLST appear, timestamps should be exact. If only plain LIST output appears, upload a test file with a known modification time and compare the displayed remote time against the server's actual clock (e.g., run date over SSH) to measure the drift.
Uncertainty notes
Behavior has varied across FileZilla versions, so confirm your version via Help → About before drawing conclusions. Also note that some servers return MLST times with a local-time component rather than UTC; parsing in that case is server-dependent and not guaranteed. If you are seeing drift even with MFMT advertised, share the server software and the FEAT response — that detail changes the diagnosis.
filezilla