Logs (and last sync date) showing in UTC instead of local time

[pje]

Just started playing with FFS today, and noticed that the logs are all recording times in UTC, and the "Last Sync" column is showing UTC as well. My computer (running Windows 10) is configured for the US Eastern time zone, so the times are off by five hours.

Anybody know how to fix this, or is this something you just have to live with? I tried running with an explicit `TZ` environment variable, but it seems to only accept the outdated `EST5EDT` format, not the modern `America/New_York` format, so I'd need to set the TZ var only for FFS, which is pretty near impossible to do sanely on Windows. There also don't seem to be any configuration settings in FFS itself for this, nor in the GlobalSettings.xml file.

[Plerry]

Essentially all modern file systems use UTC for their creation, modified and accessed file datetime.
This makes the datetime absolute and prevents any potential problems when switching between standard time and daylight saving time (DST) or when traveling across time-zones.
For that reason FreeFileSync (FFS) uses UTC when comparing files by datetime+ size.

For a older formats that use local time (like FAT32 and exFat), FFS gives the options to allow a fixed difference in datetime (see here) when translating the datetime of files from those file systems to UTC.

I suppose the FFS author (Zenju) choose to stick to UTC for all time notations in FFS (not just for comparing by datetime+size).
No translation necessary, and never an ambiguity.

I am actually surprised to see that FFS apparently followed your TZ=EST5EDT setting.
Or did I misunderstand you?

[Zenju]

FreeFileSync uses Windows time conversion functions to get local time. Most likely your OS is misconfigured in this regard.

[pje]

Which Windows time conversion functions? I can look up the docs to see where they get their configuration from then. Running `tzutil /g` at a cmd prompt shows "Eastern Standard Time", so it's not clear what the configuration problem would be. (Especially since I only set it once, when I installed the OS -- and the same issue shows up on another Win10 machine where, again, I only set it once when I installed the OS.)

That FFS is ignoring the registry and using TZ instead (if set) suggests that it's actually using generic C/C++ APIs rather than a Windows-specific API, or that perhaps there's some other edge case involved (maybe it doesn't have registry access for some reason?).

All that being said, it's not a big deal; if I need to use TZ to get it to work I can, and if I start it by GUI I can just mentally subtract five hours if I have to. But if it's actually a Windows configuration issue that could affect other apps, then of course I'd like to fix that.

[Zenju]

What times are you talking about specifically, ideally showing them with screenshots. E.g. there is no time shown in "Last Sync" column.

[pje]

Screenshot 2025-03-03 043806.gif (46.97 KiB) Viewed 476 times

The times in the last sync column are 5 hours off, showing in UTC rather than local time.

[Zenju]

These are using wcsftime with the "%R" argument which should be equivalent to "%H:%M". You're right this is indeed affected by the C locale, but apparently it's an issue only on your system. FreeFileSync sets the C locale to empty "" on startup, which results in the user-preferred locale being picked.

[pje]

Hm. wcsftime doesn't do time conversion, it looks like it's using localtime_r for that. I can't find that in the MSVC++ runtime docs, but localtime does mention that it should use the registry and fall back to Pacific time if no TZ is set and it can't get the data from the registry. (It's definitely not doing that, it'd be wrong 3 hours in the opposite direction.)

The same thing happens on my laptop, btw, so it's not specific to my desktop. Both machines are refurbs, Windows 10 Pro (but not from the same supplier), and I haven't done anything special with locale, time zone, or date/time prefs on either since selecting US/English and Eastern Time at activation.

But like I said, it's not a huge deal, just have to remember to subtract 5 hours from everything, including the times shown in the log pane and log files. (Further evidence that it's the localtime conversion rather than the formatting function, I guess.)

[Zenju]

Sorry, my concentration is all over the place. You're right wcsftime doesn't do time conversion. localtime_s is used before that.

If the TZ variable isn't set, localtime_s attempts to use the time zone information specified in the Date/Time application in Control Panel. If this information can't be obtained, PST8PDT, which signifies the Pacific time zone, is used by default..

"Date/Time application in Control Panel" means GetTimeZoneInformation is called. Perhaps this is failing in your case, but I see no reason why this should ever happen.

[therube]

(Since we're talking time zones, Looking for an Add-on to Modify Timestamps.

Likewise you can check your current timezone from a C: prompt (in Windows).

C:\> TZUTIL /G
Eastern Standard Time
C:\>


)