Timestamp of file modified "in the future" not shown over shell link to remote with timezone ahead of local

[tredondo]

Is there an existing issue for this?

• I have searched the existing issues

Midnight Commander version and build configuration

GNU Midnight Commander 4.8.31
Built with GLib 2.80.0
Built with S-Lang 2.3.3 with terminfo database
Built with libssh2 1.11.0
With builtin Editor and Aspell support
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With support for X11 events
With internationalization support
With multiple codepages support
With ext2fs attributes support
Virtual File Systems:
 cpiofs, tarfs, sfs, extfs, ext2undelfs, ftpfs, sftpfs, shell
Data types:
 char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;

Operating system

Linux laptop 6.14.0-123037-tuxedo #37~24.04.1tux2 SMP PREEMPT_DYNAMIC Fri Jan 23 22:31:21 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

Is this issue reproducible using the latest version of Midnight Commander?

• I confirm the issue is still reproducible with the latest version of Midnight Commander

How to reproduce

1. In one right panel, establish a Shell link to a machine whose time zone is ahead of the local timezone by e.g. 3 hours
2. On that remote machine, touch a few files with their timestamp set to be within the past 3 hours, but "in the future" from the perspective of the local machine. For example, it is now 2026-03-26 15:20 US Pacific, and the remote's timezone is US Eastern. On the remote:

$ touch -t 202603091530 1530.txt
$ touch -t 202603091630 1630.txt
$ touch -t 202603091600 1600.txt
$ touch -t 202603091615 1615.txt
$ touch -t 202603091625 1625.txt
$ date
Mon Mar  9 18:20:24 EDT 2026

4. Refresh the panel

Expected behavior

The Modify time should include the hour and minute ("Mmm HH:MM") for files modified the same day, even if that modification time appears to be "in the future".

Actual behavior

Notice that files touched after about 45+ minutes since the current time, have their Modify time shown as today's date ("Mmm D YYYY") instead of the more useful hour and minute ("Mmm D HH:MM").

Additional context

On the remote, ls shows the HH:MM modify time for all files:

$ ls -go
total 68
-rw-rw-r-- 1     0 Mar  9 15:30 1530.txt
-rw-rw-r-- 1     0 Mar  9 16:00 1600.txt
-rw-rw-r-- 1     0 Mar  9 16:15 1615.txt
-rw-rw-r-- 1     0 Mar  9 16:25 1625.txt
-rw-rw-r-- 1     0 Mar  9 16:30 1630.txt
-rw-rw-r-- 1     6 Mar  9 18:07 bug.txt
-rw-rw-r-- 1 17444 Mar  9 02:15 file1.txt
-rw-rw-r-- 1  6810 Mar  4 09:54 file2.txt
-rw-rw-r-- 1 35903 Mar  9 01:49 file3.txt

[mc-worker]

GNU Midnight Commander 4.8.31

Your mc is too old. Please check the latest release or git master snapshot.

[egmontkob]

Can you please try this quick path: mc-5059-shell-link-utc.patch

The core problem is that the remote side sends the timestamp according to its timezone, and the local side interprets it according to its timezone.

This is conceptually bad, communication should happen in UTC.

It is the expected behavior that future timestamps show the year rather than hour:minute, this is what ls -l or ls -go also does. The problem is not with formatting-displaying, the problem is an actual faulty belief of the timestamp.

The patch (or rather, this area of mc) surely needs more work. I'm using the timegm() function which may not be portable enough. The remote side can send the timestamp in two different formats (SHELL_HAVE_DATE_MDYT or not), later denoted by d vs. D which are parsed differently, I modified both parsers but only tested d which is used on my system. There is another occurrence of using local time which I've kept for now, but we should really revise.

---

According to your screenshots, on the remote machine you create the file 1530 with that site's local time of 15:30, and locally (over shell link) it also shows up as 15:30. I don't understand this. This is of course the intended behavior, but with current mc it should be displayed with an offset of the timezone difference.

Further investigation might be needed.

touched after about 45+ minutes

This is yet another data point that's a mystery to me.

[egmontkob]

Unlike ls which has no slack to the future (a file even a tiny bit in the future is shown with the year instead of hour:minute), mc has a tolerance of one hour into the future to show hour:minute.