Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#10818 closed Bug report (fixed)

Alternative Midnight Format Causes 24:00 To Be Prefixed To the File Name & Unable To Retrieve

Reported by: Bob Hoblit Owned by: Tim Kosse
Priority: normal Component: FileZilla Client
Keywords: alternative midnight format 24:00 00:00 Cc:
Component version: 3.16.1 Operating system type: Windows
Operating system version: 10

Description

We connect to a client which uses Alternative Midnight Format (24:00) timestamps when retrieving directory listings using sFTP.

This system has logs, several of which roll at midnight, making the occurrence of these timestamps somewhat common.

When a directory listing is performed against the server, the data returned is:

(file name = testdate, 
 file size = 3 bytes, 
 file timestamp = 4/5/2016 00:00 == 4/4/2016 24:00)
1459828800 -rw-------    1 99999999 0               3 Apr  4 24:00 testdate

The client window shows the file name as "24:00 testdate" and properly shows the date/timestamp as 2016-04-05 00:00 when using ISO 8601 format.

When retrieving the file, the command sent is:

get "24:00 testdate" "c:\temp1\24_00 testdate"

and fails because the file indicated in the command does not exist. Other commands against the file also fail for the same reason.

It is my understanding that ISO 8601 indicates midnight as 00:00 or 24:00 of the day prior, both being valid formats.

Change History (5)

comment:1 Changed 4 years ago by Tim Kosse

Owner: set to Tim Kosse
Status: newaccepted

I hate date/time parsing.

Personally I'd use a metric base-10 time, where there are just seconds, kiloseconds and megaseconds.

Timezones and daylight savings time should be made illegal.

comment:2 Changed 4 years ago by Tim Kosse

Resolution: fixed
Status: acceptedclosed

A fix has been committed to the repository.

comment:3 Changed 4 years ago by Bob Hoblit

codesquid,

I downloaded last night's nightly as the ticket indicates that the code was committed to the repository, however, I observed the same results. Is there a way that I can determine if the nightly build included this change?

Thanks,
rsh

comment:4 Changed 4 years ago by Tim Kosse

Last night's nightly hadn't been built successfully, so you haven't actually gotten the fix yet.

comment:5 Changed 4 years ago by Bob Hoblit

Thank you CS, verified on the most recently released 3.0.17 and it is working successfully with the server.

rsh

Note: See TracTickets for help on using tickets.