shared folders file date mismatch

[agreppin]

Describe the bug Files created on host shared folders are created with GMT time.

To Reproduce Steps to reproduce the behavior:

1. harddrives / add directory as DH1 Work:
2. echo 1 > work:t1
3. echo 2 > ram:t2
4. list work:t1 ram:t2 ; inspect dates
5. setdate work:t1
6. list work:t1 ; file date is ok now

Expected behavior Both files should have the same date and time.

Screenshots

Desktop:

• OS: Ubuntu 24.04
• Version: Amiberry 7.0.2

[agreppin]

some more info on this, testing now on UTC+2 / DST the difference is 2 hours now and the final date of t1 as set by setdate is 2 hours in the future on the host fs. (my system has hwclock is set to UTC).

agreppin@host:~/Amiberry/harddrives/DH1$ 
✓ → TZ=UTC stat t1
  File: t1
  Size: 2         	Blocks: 8          IO Block: 4096   regular file
Device: 259,3	Inode: 2763417     Links: 1
Access: (0775/-rwxrwxr-x)  Uid: ( 1000/agreppin)   Gid: ( 1000/agreppin)
Access: 2025-04-02 22:37:17.020000000 +0000
Modify: 2025-04-02 22:37:17.020000000 +0000
Change: 2025-04-02 20:37:17.817725065 +0000
 Birth: 2025-04-02 20:37:17.809725029 +0000
agreppin@host:~/Amiberry/harddrives/DH1$ 
✓ → stat t1
  File: t1
  Size: 2         	Blocks: 8          IO Block: 4096   regular file
Device: 259,3	Inode: 2763417     Links: 1
Access: (0775/-rwxrwxr-x)  Uid: ( 1000/agreppin)   Gid: ( 1000/agreppin)
Access: 2025-04-03 00:37:17.020000000 +0200
Modify: 2025-04-03 00:37:17.020000000 +0200
Change: 2025-04-02 22:37:17.817725065 +0200
 Birth: 2025-04-02 22:37:17.809725029 +0200
agreppin@host:~/Amiberry/harddrives/DH1$ 
✓ → date
Wed Apr  2 10:46:09 PM CEST 2025

Edit 1: the Locale on Amiga side is the default US, 5 Hours from GMT

[midwan]

I can recreate this, but I haven't figured out where the issue comes from. All the operations that set a date, seem to be using the correct local datetime. Normally, in the case of using a filesystem as a drive, the OS itself should be setting the datetime on the created files directly.

[simpsond]

Hello midwan, Thank you for all your work on Amiberry. I love it!!

I've been looking into this issue, and I believe I have identified the root cause of the problem.

As you pointed out, the OS does set the datetime on the created files directly. However, it does so using a UTC timestamp. The problem is that the Amiga OS expects timestamps to be in local time, but Amiberry does not perform the necessary conversion from UTC to local time.

This is why the timestamps are being displayed in GMT instead of the local time.

The fix is to calculate the local time zone offset and then subtract it from the UTC timestamp to obtain the correct local time.

I have created a standalone test case that demonstrates the problem and the fix. The test case does the following:

1. It creates a timestamp for a specific local time.
2. It then converts this local time to a UTC timestamp, which is what the OS would do.
3. It then shows the "flawed" behavior by interpreting the UTC timestamp as a local time, which is what Amiberry is currently doing.
4. Finally, it shows the "fixed" behavior by subtracting the timezone offset from the UTC timestamp to get the correct local time.

This test case is intended to demonstrate that the proposed fix is both necessary and correct.

#include <iostream>
#include <time.h>
#include <string.h>
#include <string>

// This function calculates the difference in seconds between the host's local time and UTC.
// It is the core of our fix.
[[nodiscard]] static time_t get_local_time_offset(time_t t)
{
    struct tm lt;
    localtime_r(&t, &lt);
    struct tm gt;
    gmtime_r(&t, &gt);
    gt.tm_isdst = lt.tm_isdst;
    return t - mktime(&gt);
}

// Helper function to convert time_t to a string
std::string time_to_string(time_t t)
{
    char buf[100];
    strftime(buf, sizeof(buf), "%Y-%m-%d %H:%M:%S", localtime(&t));
    return std::string(buf);
}

int main()
{
    // --- The Scenario ---
    // A file is modified on the host machine at a specific local time.
    // The host OS (macOS, Linux, etc.) stores this modification time as a UTC timestamp.
    // Amiberry reads this UTC timestamp.
    // The Amiga OS, however, expects a local time timestamp.

    // --- Create a Test Timestamp ---
    // Let's say the local time is "2025-07-15 12:00:00".
    struct tm local_tm;
    memset(&local_tm, 0, sizeof(local_tm));
    local_tm.tm_year = 125; // 2025
    local_tm.tm_mon = 6;    // July
    local_tm.tm_mday = 15;
    local_tm.tm_hour = 12;
    local_tm.tm_isdst = -1;
    time_t local_time = mktime(&local_tm);

    // The OS would store this as a UTC timestamp.
    time_t utc_time = local_time + get_local_time_offset(local_time);

    std::cout << "--- The Test ---" << std::endl;
    std::cout << "File was modified at local time: " << ctime(&local_time);
    std::cout << "The OS stores this as UTC time: " << ctime(&utc_time);

    // --- The Flawed Behavior ---
    // The original Amiberry code took the UTC time from the OS and used it directly,
    // as if it were a local time. This is incorrect.
    time_t flawed_amiga_time = utc_time;
    std::cout << "Flawed Amiga Time (UTC interpreted as local): " << ctime(&flawed_amiga_time);

    // --- The Fix ---
    // The corrected code takes the UTC time and subtracts the timezone offset,
    // converting it back to the correct local time.
    time_t fixed_amiga_time = utc_time - get_local_time_offset(utc_time);
    std::cout << "Corrected Amiga Time (UTC converted to local): " << ctime(&fixed_amiga_time);

    // --- Verification ---
    if (time_to_string(fixed_amiga_time) == time_to_string(local_time)) {
        std::cout << "Result: PASS - The corrected time matches the original local time." << std::endl;
    } else {
        std::cout << "Result: FAIL - The corrected time does not match the original local time." << std::endl;
    }

    return 0;
}

[midwan]

Should be fixed with the merged PR above