time display

[JeanneMarie]

I adjusted the creation and modification date and time on a file. The dialog box reflects those changes but MultiCommander's file manager displays one hour earlier in each case. It's as if the program thinks I'm in a different time zone. I just updated MultiCommander but no difference. The dialog box and the file display tell different times.

But I have no problems with any other dates in any other programs. How can i troubleshoot this?

Thanks very much,
JeanneMarie
using Windows 11 and
MultiCommander x64 ver. 15.2.0.3077

[Mathias (Author)]

Im not able to reproduce that.

Can you describe exactly what you are doing.

[JeanneMarie]

Thanks for your reply.

I open MultiCommander and see a file manager interface. I select the file you see selected in file_mgr.jpg. When I choose TOOLS > CHANGE PROPERTIES (dialog(tools-change_prop).jpg), I see the created and modified date and times I set earlier today for that file. But as you can see, in file_mgr.jpg, the times displayed in the file manager are one hour earlier.

Let me add that the date and time on the file originally were altogether different before I changed them today. I cannot honestly tell you whether they were accurate. But I just did a quick test, creating a new little text file, and the date and time (both created and modified) display correctly in the file manager. I change the created and modified times and they displayed fine.

One last thing just occurred to me regarding the troublesome file (2024estJan5.ods): I restored that file today from a cloud backup (CrashPlan). Hence my desire to have the file reflect when it was really created and modified. Could this have anything to do with this strange behavior?

Happily this is not mission critical stuff. Still, inquiring minds want to know....

Thanks again for any input,
Jeanne

[Mathias (Author)]

The columns.. are both the date columns the extended columns ? or are modified the standard "date" column. ?
If you enable the standard date column and extended date modified column, do they show same or different time ?

If it is extended modified date column.. Have you forced a refresh ?,  A lot of the extended column will cache there values.. and a force refresh will reload them

Also the filesystem is normal NTFS ? or mapped to network share ? or FAT32/FatEx filesystem ?

[Mathias (Author)]

A wait I think that is the famous Daylight saving issue.

All file dates are stored in the file system as UTC (except Fat32..and some other old filesystem)
When a date is shown the date is normally translated your timezone plus DTS (daylight saving).

Problem is that when you view a date that is 1-May 2025 11:00, (Summer time, DST) but you view in during normal time (NO DST)

Should the date be shown with or without DST. both are correct. depending on view point.

In Exploer Panel settings. under Date / Time format. There is an option for "Adjust datetime for DST"

[JeanneMarie]

Mathias,

Thanks so much for your reply.

I too thought it was something like DST at work, but that doesn't quite explain why it seemed to be just this file. Hence my questioning whether restoring from cloud backup who-knows-where might be a factor.

But now, when I randomly select a few files in this single directory, and then go to TOOLS > CHANGE PROPERTIES...  sometimes both dates agree with the explorer panel, sometimes one agrees, and sometimes neither agrees.

In any case, when I choose CONFIG > EXPLORER PANEL SETTINGS, "adjust datetime for DST" is checked.

To backtrack to earlier questions:
This is Win 11.
The file system is NTFS.
The file is on a partition on my main hard drive. No networking at work.
Yes I had refreshed, and indeed since I posted, I have re-started.

When I customized columns, I saw that the two date columns were extended. So I added standard. And that's reflected in the new image attached. It's the same time.

Sooooo.... as I said (and thank heavens), this is not mission critical. Changing the date was way more important than the time and remains so. I just wanted to understand what appears to be an anomaly.

But  what is MultiCommander telling me here about the selected file? I set the modified time at 1:47pm but MultiCommander displays 12:47pm because my locale is on DST today? But it wasn't on DST in January (the date of the file). I'm still not sure what to do if/when changing the time might be important.

Continue only as this intrigues you. But thanks again,
Jeanne

[Mathias (Author)]

So the dates are 5-Jan . och not 1 May?

I'm not able to reproduce it.

Since the different is 1h it look like a DST issue.  But unless you are in australia (or south america), you should not have DST in Januari.
What dates do you get if you uncheck "adjust datetime for DST"

Hmm are you in a timezone that already entered DST ? then when you set the time 1:47 the time really is 12:47 when you remove the DST..   So Showing it as 12:47 because adjust for DST is enabled, so it removed the DST of the time since 5-January does not have DST.

NTFS stores the dates as UTC.  then for viewing the timezone and possible DST is added.

[JeanneMarie]

First, FYI, there was never a problem with the dates. The issue has only been the time.

But wow, yes. When I changed this date and time (two days ago on the Jan. 5 file), we had already entered DST (a couple of weeks earlier).
And yes, when I uncheck "adjust datetime for DST"  I get the same time as the change dialog displays (the time I entered).

So a step further: When I now change the time on that Jan. 5 file to 2:47p, the "correct" time of 1:47 displays (the time I entered).

But what happens when we go on standard time? I think it will say the wrong time (2:47).

And therefore, I think the rule is... when I enter a new time, the current regime (DST vs. Standard) will control rather than the date on the file.

It may be true that the experts instantly recall that the file system uses UTC, but if nothing else, this deserves some mention in the documentation--specifically with respect to this dialog (change properties). If it's there, mea culpa, I missed it.

Gosh, with all the discussion of ditching this changing of regimes twice a year, here's another good reason.

Thanks for so much help in clarifying what's happening. That is way more than half the battle,
Jeanne

[Mathias (Author)]

The date/time is the same. A Timestamp that a file has in NTFS is the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 (UTC).
So Time and Date are not set separate. it is one very big value.

So a step further: When I now change the time on that Jan. 5 file to 2:47p, the "correct" time of 1:47 displays (the time I entered).

But what happens when we go on standard time? I think it will say the wrong time (2:47).

And therefore, I think the rule is... when I enter a new time, the current regime (DST vs. Standard) will control rather than the date on the file.

"Adjust for DST" is only for display in filelist.
The problem is that local time is used when settings the timestamp. Sometimes you might want to use the date from the specified timestamp.
Problem is if it should use date from the timestamp to set. and then viewing it.. it would be wrong if DST did not match with local.
Maybe a checkbox in the Set filetime dialog that lets you decided.. but then we got more advanced option that people will not understand.

The problem is no matter what you do there are senarios where it shows wrong. If you really need exact time always. then go for showing time in UTC.

DST/Timezone are tricky.. there are even special timestamp ranges in local time that is impossible to convert to UTC
(When you switch the clock back.. at 02:59 -> 02:00   that day. the local time is 02:00 -> 02:59 twice, )

[JeanneMarie]

If you really need exact time always. then go for showing time in UTC.

Meaning DE-select that "adjust datetime for DST" checkbox? That's what I've been thinking (along with thinking I'm happy this is not hugely important to me).

But serious thanks again. I feel so knowledgeable!