Opened 14 years ago

Closed 9 years ago

#5367 closed Bug report (fixed)

7-hour error on timestamp for all sent files

Reported by: John O'Leary Owned by:
Priority: normal Component: FileZilla Client
Keywords: timestamp, Last Modified Cc:
Component version: Operating system type: Windows
Operating system version: Windows XP Pro SP3

Description (last modified by Tim Kosse)

Two parties have verified that text files sent via FileZilla show a new "last modified date" that is seven hours ago. Yet, others looking at the same files on the remote server using SQL Tools 1.5 see the correct timestamp.

I am using Windows XP Pro SP3, and the files are being transferred to any of several servers. In the Site Manager, we have the timezone offsets set to zero (in fact, the seven-hour error is in the wrong direction for this to be the difference between PDT and GMT.)

Here's the kicker: if you drag the affected file back from the remote server, it keeps the same wrong timestamp!

Love the product, just trying to help make it better...

Change History (3)

comment:1 by Tim Kosse, 14 years ago

Status: newmoreinfo

Does your server obey the FTP specifications by returning timestamps in UTC on the MDTM and MLSD commands?

in reply to:  1 comment:2 by John O'Leary, 14 years ago

Status: moreinfonew

Replying to codesquid:

Does your server obey the FTP specifications by returning timestamps in UTC on the MDTM and MLSD commands?

Responses from server staff:

"Server time is correct"

"The problem is reproducible with both Filzilla and WinSCP but not SSH cmd has no problems.

FileZilla I believe you are familiar with. WinSCP (Windows Secure CoPy) is an open source FTP tool for secure file transfers, usually between a local and remote device. SSH (Secure SHell) is also a secure data exchange, but uses a channel between two network devices. FileZilla is used for cross-platform transfers too, so maybe the issue comes from going outside the network. But according to Scott, the server date/time is current PST. Looking at GMT seemed to have some merit, but the time used is seven hours in the other direction, so that probably has no basis. Given that the minutes used remain unchanged it definitely seems to be a time zone issue – meaning it does not apply a new date/time stamp – but which time zone? Seven hours earlier does not exist in the current day and the date did not change either on the file. Makes no sense."

comment:3 by Tim Kosse, 9 years ago

Description: modified (diff)
Resolution: fixed
Status: newclosed

There have been improvements to timezone handling in recent FileZilla versions.

Note: See TracTickets for help on using tickets.