Opened 11 years ago

Closed 10 years ago

Last modified 9 years ago

#7769 closed Bug report (outdated)

Odd date sort behavior at start of UTC month

Reported by: Tim Parenti Owned by:
Priority: normal Component: FileZilla Client
Keywords: date, sort, utc, month Cc: tjtrumpet2323@…
Component version: Operating system type: Windows
Operating system version: Windows 7 Professional SP1 x64 on Intel Core i5-2410M


When sorting files on a remote server by date, weird behavior occurs at the UTC month boundary. Sorting by ascending date puts files from 01 October (UTC) before files from 28, 29, and 30 September (UTC). Expected behavior would list files chronologically, with 01 October (UTC) coming after the others.

Both my computer and the remote server operate in America/New_York (currently UTC-04:00), so the start of October (UTC) was at 20:00 EDT on 30 September.

See attached screenshot.

FileZilla Client

Version: 3.5.1

Build information:

Compiled for: i586-pc-mingw32msvc
Compiled on: x86_64-unknown-linux-gnu
Build date: 2011-08-28
Compiled with: i586-mingw32msvc-gcc (GCC) 4.2.1-sjlj (mingw32-2)
Compiler flags: -g -O2 -Wall -g -fexceptions

Linked against:

wxWidgets: 2.8.12
GnuTLS: 2.10.4

Operating system:

Name: Windows NT 6.1 (build 7601, Service Pack 1)
Version: 6.1
Platform: 64 bit system

Attachments (1)

2011-09-30_filezilla-timestamp-sort-bug_redacted.png (70.1 KB ) - added by Tim Parenti 11 years ago.
Files from 20:15-22:42 on 30 Sep (which is 1 Oct, UTC) appear as being chronologically BEFORE files from earlier in September.

Download all attachments as: .zip

Change History (7)

by Tim Parenti, 11 years ago

Files from 20:15-22:42 on 30 Sep (which is 1 Oct, UTC) appear as being chronologically BEFORE files from earlier in September.

comment:1 by Tim Parenti, 11 years ago

Cc: tjtrumpet2323@… added

in reply to:  description ; comment:2 by Tim Parenti, 11 years ago

It seems, upon further inspection, that this is because the dates from 01 October (UTC) are being reported by FileZilla as dates in 2010 and not 2011, even though all of the files shown were uploaded in 2011.

in reply to:  2 comment:3 by Tim Parenti, 11 years ago

Now that we've hit 01 Oct 00:00 local time (04:00 UTC), all of the files are being reported as dates in 2011 as expected. It's hard to generalize here, but the buggy behavior only seems to occur when referring to a month boundary NEAR said boundary (specifically, when the current UTC month and local month differ).

comment:4 by Alexander Schuch, 11 years ago

Status: newmoreinfo

According to the screenshot, the items are sorted chronologically.

If you still have that issue, can you please provide a screenshot and a log showing the raw directory listing? -

in reply to:  4 comment:5 by Tim Parenti, 11 years ago

Replying to ci-dev:

According to the screenshot, the items are sorted chronologically.

Yes, it appears this way in the screenshot, but as I mentioned in comment 2, the items from 01 October (UTC) were given the wrong year. No files were actually uploaded to this directory in 2010. New submissions between 20:00 and 23:59 EDT on 30 September 2011 (00:00 and 03:59 UTC on 01 October 2011) were being erroneously listed as 2010.

Notice how the submissions listed at the bottom are all before 20:00 EDT, and all the ones at the top are after 20:00 EDT. These were all from the same day, 30 Sep 2011 (local), and I watched new submissions come in and be erroneously inserted as though they were a year old.

Given the narrow time window during which this occurs (apparently, between 00:00 UTC and 00:00 local on a month boundary), I'll try to see if I can replicate this behavior with logs on the upcoming Jul/Aug 2012 boundary and will check back in.

comment:6 by Alexander Schuch, 10 years ago

Resolution: outdated
Status: moreinfoclosed

No reply for more than 28 days.

If you can still reproduce the problem, please reopen this issue and attach logs with "raw directory listing" enabled -

Note: See TracTickets for help on using tickets.