Modified File Time and Daylight Savings Time NTFS

bug-fixed

#1

Pardon me if this has already been addressed, but the topic did not come up in my search. Have you considered adjusting the modified file date function for NTFS files so the modified time reflects the actual local time a file was modified with regard to Daylight Savings and Standard Time?

Currently MP3Tag appears to display the current equivalent of the UTC time, without regard to whether the file was modified during Daylight Savings Time or Standard Time. As a result, during Daylight Savings Time, all files last modified during Standard Time show a modification time one hour later than was the actual case, and, during Standard Time, all files last modified during Daylight Savings Time show a modification time one hour earlier than was the actual case. Instead of converting a file’s UTC file time directly to local time, the time should first be converted to “specific” local time (see the URL below). File modification times would then be actual times instead of a mere reference to the UTC relative only to the current daylight savings time regime; modification times would then also match those displayed by Microsoft Windows.

https://msdn.microsoft.com/en-us/library/wi...0(v=vs.85).aspx


#2

My computer is set to timezone Germany, currently CEST Central Europe Summer Time:
GMT/UTC=+1.0 hour, with currently DST Daylight Saving Time=+2 hours

Mp3tag displays the same file modified time stamp in the file properties dialog ...
as it does in the variable %_file_mod_datetime%, ...
and the same as in Windows Explorer.

See Mp3tag/Tools/Options/Tags ...
Option "Preserve file modification time when saving"
When this option is set to "off", the currently saved file will get the current system time as the file modification time.
When this option is set to "on", the existing modification time will not be changed.

As a long time user of Mp3tag I cannot remember to have any problem with files and their time attributes.
Please elaborate your problem and offer a concrete test case.

Are you saying that the file modification time differ by the summertime difference in hours, between the areas of wintertime and summertime?
With the possible result that the identical file modification time is displayed one hour younger or older in relation to the current timezone setting?
Isn't such file time management the basic task of the operating system, but not of the software applications?

Note:
The SystemTimeToTzSpecificLocalTime function may calculate the local time incorrectly under the following conditions:
-The time zone uses a different UTC offset for the old and new years.
-The UTC time to be converted and the calculated local time are in different years.

DD.20150708.1022.CEST


#3

The issue is solely how MP3Tag renders the file modification time, regardless of whether the tags have ever been modified by MP3Tag. The issue has nothing to do with the MP3Tag option for preserving the original file modification time when changing tags. (I mostly use MP3Tag to retrieve existing file and tag information and almost never edit tags.)

On my system, Windows 7, the issue is present in both the file properties dialog and in the variable %_file_mod_datetime%.

The issue is present only with files whose last modification date was in the alternate time regime, that is, when displaying, during Daylight Savings Time, files whose last modification time occurred during Standard Time, or displaying, during Standard Time, files whose last modification occurred during Standard Time.

Example:

I have a folder of MP3 files that I burned from the CD “The Wonderful World of Louis Armstrong” on January 2, 2013. Windows Explorer shows the modified times beginning at 5:27 p.m. If I obtain a folder listing via PowerShell (a simplified version of the command appears below), the LastWriteTime agrees with the times displayed in Explorer; the UTC times begin at 10:27 p.m. That looks correct as I am in the Eastern Time Zone in the United States, which, in January, is under Standard Time and is UTC+5.

 Get-Childitem | Select Name, Directory, LastWriteTime, LastWriteTimeUTC, Mode, Length 

Now that it is July 2015, my computer is set to Eastern Daylight Savings Time, or UTC+4.

When I look at the same folder with MP3Tag, both the file properties and the variable show the modified times starting at 6:27 p.m. I suspect that MP3Tag is converting the NTFS time of UTC 10:27 p.m. using my current UTC offset of 4, instead of converting it based on the UTC offset of 5 that was in effect in January, when the files were modified.

I will note that other applications also demonstrate this flaw (if it is a flaw). TotalRecorder and Foobar’s file properties both also give the modification times for these files starting at 6:27 p.m. (I can't find a modification time among file properties for Media Player, Winamp, or VLC.)

My programming is generally limited to VBA, and if I use available VBA procedures (FileSystemObject.FileDateTime, or FileScriptingObjects’s file object.DastLastModified) (independently from MP3Tag, in my own Microsoft Access database), I get the same file modification times as MP3Tag. However, if I use Windows APIs to retrieve the modification times and convert them to “specific” time (using SystemTimeToTzSpecificLocalTime) instead of to “local” time, the modification times match those displayed in Windows Explorer, beginning at 5:27 p.m.


#4

Sorry, I cannot see any bugs.
MP3tag's display is consistent with the systems display.
If you use methods that access the raw date, you get the basic UTC, the universal time coordinate.
You can calculate your local time with the according offsets.
Usually, the OS does that for you. But there may be special applications where you need to see the raw UTC.
You are free to define your own column contents or field that un-does the OS calculation with time-offsets so that you see the basic UTC again.


#5
  1. Could it be that "SystemTimeToTzSpecificLocalTime" is related only to countries without any DST correction ... or the other way round?

  2. Does the following question relate to your theme in any way?
    http://www.codeproject.com/Questions/66570...ecificLocalTime

  3. See also ...
    http://msdn.developer-works.com/article/11...f+on+Windows+XP
    http://ghisler.ch/board/viewtopic.php?p=218382
    http://blogs.msdn.com/b/oldnewthing/archiv...7/10505926.aspx

  4. Maybe the point is the currently used filesystem (FAT32, NTFS) ...
    http://ghisler.ch/board/posting.php?mode=q...bb97e3ed74b305a

DD.20150710.1055.CEST


#6

This issue appears only if the setting “Automatically adjust clock for daylight saving changes” is checked in Windows Date and Time Properties. Otherwise the difference between UTC and local time (for example 5 hours for the Eastern Time Zone of the United States) does not vary during the year. The issue is present with the NTFS system. It does not affect the FAT system because FAT stores only local times. The issue is an improper conversion of UTC to local time by applications.

If a system adjusts for daylight savings time, file modification times for files saved in the winter disagree between Windows Explorer and MP3Tag when viewed in the summer. If the system date is changed temporarily from summer to winter, those winter file dates now agree but summer file dates do not. If the automatic adjustment for daylight savings time is turned off, the issue disappears entirely.

I discovered this issue after I used PowerShell instead of MP3Tag to retrieve local file times and found that they did not agree for the files described. Looking at those files in Windows Explorer confirmed the discrepancy. Additionally, retrieval of UTC times confirms that times displayed in Windows Explorer are correct while the times retrieved by MP3Tag, other applications, and VBA functions (that convert FileTime to SystemTime to LocalTime) are incorrect.

One of the links provided above grasps the issue but muddles its explanation. I will restate the issue slightly differently, correcting an error regarding System­Time­To­Tz­Specific­Local­Time:

Using File-Time-To-Local-Time conversion does not work well because it uses the time zone in effect right now--at the time of the conversion, in other words, when MP3Tag reads file information from the file system. System­Time­To­Tz­Specific­Local­Time instead uses the time zone in effect at the time the file was modified (NOT when converted, as stated in the blog, for then the two conversions would be identical).

(see http://blogs.msdn.com/b/oldnewthing/archiv.../10505926.aspx)

I don’t know if System­Time­To­Tz­Specific­Local­Time works correctly for files saved during years when different daylight savings time rules were in effect. It is clear, however, that File-Time-To-Local-Time does NOT work correctly for ANY files saved during a different daylight savings time regime on a system that automatically adjusts for daylight savings time.


#7

I just went over this issue again and it seems that I've fixed it as a byproduct of one of the recent internal re-implementations.

I'm in an UTC+1 time zone right now and a file modified during UTC+2 shows correctly in PowerShell and Mp3tag.


closed #8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.