Update s3fs.go

[fdefilippo]

Convert S3 UTC Time to Local

Checklist for Pull Requests

• Have you signed the Contributor License Agreement?

---

[CLAassistant]

All committers have signed the CLA.

[drakkan]

Thanks for this PR. I assume it’s related to file listings returned by the sftp CLI. Have you also tested the modification times in other clients, such as FileZilla or WinSCP, as well as in the SFTPGo WebClient?

Could you clarify the reasoning and use cases for these proposed changes? The code might need some improvements, but we can tackle those later if the change is accepted.

[fdefilippo]

Thanks for this PR. I assume it’s related to file listings returned by the sftp CLI. Have you also tested the modification times in other clients, such as FileZilla or WinSCP, as well as in the SFTPGo WebClient?

I have verified that file modification times are correctly displayed using the following clients, in addition to the SFTP CLI:

FileZilla
WinSCP
SFTPGo WebClient

In all tests, the returned time zone is consistent and correct after applying the patch.

Could you clarify the reasoning and use cases for these proposed changes? The code might need some improvements, but we can tackle those later if the change is accepted.

Rationale and Use Cases (Reasoning Behind Proposed Changes)

The primary motivation for this change lies in the non-standardized and often inconsistent handling of file timestamps when using Object Storage (S3) endpoints, such as MinIO or AWS S3.

The Core Problem

S3 providers (including MinIO and AWS, which were tested) return file modification timestamps (last modified time) exclusively in the UTC (Coordinated Universal Time) format.

Use Case and Proposed Solution

End-users, however, require that these timestamps be displayed in the server's or client's Localtime for critical operational reasons:

Operational Consistency: Most tools for backup, synchronization, and general file management rely on the system's local time zone for accurate comparisons.

Usability: Displaying a file's timestamp in UTC within a local operating environment creates confusion and leads to interpretation errors regarding the exact time a file was uploaded or modified.

The patch implements the necessary logic to convert the UTC timestamp to the local time zone of the SFTPGo server before transmitting it to the SFTP client, ensuring consistency and improved usability for all clients accessing S3 storage backends.

[drakkan]

What you describe does not match my test results.
I have a file in S3 with a timestamp of 2025-10-24 07:24:10 UTC, and the WebClient displays the local time without this change:

Also FileZilla shows local time (both FTP and SFTP)

SFTP cli instead shows UTC time (ls -l)

but local time with ls -l <filename>

This behaviour is quite clear if you are familiar with the specs

[fdefilippo]

first the object storage (minio):

$ mc --debug stat local/test/temp/test.txt
mc: <DEBUG> HEAD /test/temp/test.txt HTTP/1.1
Host: test.local.lan:9000
User-Agent: MinIO (linux; amd64) minio-go/v7.0.90 mc/RELEASE.2025-08-13T08-35-41Z
checksum-mode;x-amz-content-sha256;x-amz-date, Signature=**REDACTED**
X-Amz-Checksum-Mode: ENABLED
X-Amz-Content-Sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
X-Amz-Date: 20251024T125341Z

mc: <DEBUG> HTTP/1.1 200 OK
Content-Length: 692252
Accept-Ranges: bytes
Content-Type: text/plain; charset=utf-8
Date: Fri, 24 Oct 2025 12:53:41 GMT
Etag: "87691a7a9ac41be0fc7235d49ab9a6d2"
Last-Modified: Fri, 24 Oct 2025 12:48:04 GMT

the Last-Modified showing GMT (https://github.com/minio/object-browser/issues/2462)

whitout patch:

$ date
Fri Oct 24 02:44:37 PM CEST 2025
sftp> put /etc/services test.txt
Uploading /etc/services to /temp/test.txt
services                                                                                                                                            100%  676KB  51.0MB/s   00:00
sftp> ls -la
drwxr-xr-x    1 0        0               0 Jan 1  1970 .
drwxr-xr-x    1 0        0               0 Jan 1  1970 ..
drwxr-xr-x    1 0        0               0 Jan 1  1970 .caronte
-rw-r--r--    1 0        0          692252 Oct 24 12:44 test.txt
sftp>

with patch, sftp client:

sftp> rm test.txt
Removing /temp/test.txt
sftp> put /etc/services test.txt
Uploading /etc/services to /temp/test.txt
services                                                                                                                                            100%  676KB  47.9MB/s   00:00
sftp> ls -l
-rw-r--r--    1 0        0          692252 Oct 24 14:48 test.txt

winscp (and filezilla) with or without applied localtimestamp:

[drakkan]

try ls -la test.txt without this PR applied, you will see local time

[fdefilippo]

try ls -la test.txt without this PR applied, you will see local time

yes but not ls -la without filename:

$ sftp -P2022 test@localhost
Connected to localhost.
sftp> cd temp
sftp> ls -la
drwxr-xr-x    1 0        0               0 Jan 1  1970 .
drwxr-xr-x    1 0        0               0 Jan 1  1970 ..
-rw-r--r--    1 0        0          692252 Oct 24 12:48 test.txt
sftp>ls -la test.txt
-rw-r--r--    ? 0        0          692252 Oct 24 14:48 test.txt
sftp>

[drakkan]

Yes, because sftp cli uses file attributes in the latter case and ls formatting in the first case. It is the client that should convert timestamp in local time, the file attributes are epoch timestamps. FileZilla and WinSCP always convert in local time, this is consistent and does not assume that client and server are in the same timezone