Date off by 1 hour

jklein · 2015-03-08 22:31

I have a preset for my video files from my camcorder, where I am renaming the file with the File_DateModified metatag. Have been using this for years, no problem.

Recently did a clean re-install of Win7Pro on my computer, installed Renamer v5.60 (same version as previous build), and when I was testing to make sure Renamer was set up properly, I tried the preset on a renamed file from about a year ago, and the renamed file is off by one hour. The old file name was 2014-03-08-121414.MTS and now the new file name comes out as 2014-03-08-131414.MTS. Windows Explorer details shows the timestamp as 12:14 pm, which means the old file naming was correct, and my new rename is off. I tried it for a few video files, and they are all off by an hour. My jpg preset, which uses ExifDate, is working fine.

Coincidently, we moved our clocks ahead last night for daylight savings time, but I don't see how that would affect anything.

Ideas or suggestions?

Thanks,
jklein

jklein · 2015-03-08 23:34

More information. I just recorded a quick clip on the camcorder, copied it over, and Renamer used the correct timestamp on the rename. Weird.

den4b · 2015-03-15 16:24

Have you came across this issue again? Are you able to reproduce it?

Date/time meta tags are converted to local timezone. It is possible that you had some kind of local timezone mismatch.

jklein · 2015-03-16 17:59

The only thing I can think of is when I reset the time on my camcorder for the time change, maybe I updated the timezone to a different/correct setting. So now everything looks ok. I will have to pay a bit more attention to this as I collect and rename more files, both photo and video, to see if I find a problem or not. I was just wondering if anyone else ever had this happen. I'm usually pretty strict about changing all my devices after a time change and keeping times/dates/timezone updated.

den4b · 2015-03-16 19:12

We are not aware of anyone else experiencing this issue.

Keep an eye on it and let us know if anything new comes up.

namer009 · 2017-01-21 22:47

Hello,

I'm experiencing the same problem. I live in Pacific Time Zone, and we have Daylight saving time which is the practice of advancing clocks during warmer part of the year(second Sunday in March, 2:00am) by one hour and adjust them backward in the autumn(first Sunday in November, 2:00am) to standard time.

For the below experiments, from "second Sunday in March, 2:00am" to "first Sunday in November, 2:00am", I call it - Period1. And from "first Sunday in November, 2:00am" to "second Sunday in March, 2:00am", I call it - Period2.

Ok, now here is how to reproduce the issue(all time below are set in Pacific Time Zone):
(1) create a random file A.txt on my pc, right click it and check "Properties", it shows "January 21, 2017, 12:34:51 PM". Using ReNamer, Insert ":File_DateModified: " as Prefix, the file name become "2017-01-21 12-34-51 A.txt". Everything is fine, no problem here. Note that the original file modified time is in Period2, and I Renamer it during Period2 too.

(2) Now I change my PC time to April 13, 2017. And then right click A.txt and check "Properties", it shows "January 21, 2017, 12:34:51 PM". Using ReNamer, Insert ":File_DateModified: " as Prefix, the file name become "2017-01-21 13-34-51 A.txt". Now there is a mismatch (Hour +1). Note that in this case, the original file modified time is in Period2, and I Renamer it during Period1.

After some more similar experiments, I have the following observations:
(1) If original file modified time is in Period2, Renamer it during Period2 - No Problem.
(2) If original file modified time is in Period2, Renamer it during Period1 - Mismatch(Hour +1).
(3) If original file modified time is in Period1, Renamer it during Period2 - Mismatch(Hour -1).
(4) If original file modified time is in Period1, Renamer it during Period1 - No Problem.

These observatons also explain the user "jklein"'s case. His original file time is 2014-03-08-121414 (which is in Period2), and he ReNamer it right after the daylight saving time change(which means he's now in Period1), so he got a Mismatch(Hour +1). He tried to reproduce the issue by "recorded a quick clip on the camcorder"(modified time is in Period1) and found that "Renamer used the correct timestamp on the rename"(that is because he ReNamer it during Period1 too).

All right! Hopefully this little issue can be fixed in ReNamer's next version.

Thanks!

den4b · 2017-01-22 12:49

Thanks a lot for a detailed explanation and your time spent investigating this issue!

Now it was easy to reproduce the problem and find the underlying cause. It turns out that a Windows API function FileTimeToLocalFileTime is at fault. This function is used to convert file timestamps from UTC to local time, however, it has a bizarre logic of using DST state of current time instead of DST state corresponding to the file timestamp.

Apparently this problem affects a wide range of software including some Microsoft software even today.

For future reference, the appropriate thing to do (according to MSDN) is to use following sequence of calls instead of FileTimeToLocalFileTime:

1. FileTimeToSystemTime
2. SystemTimeToTzSpecificLocalTime (with a NULL timezone parameter)
3. SystemTimeToFileTime

This problem will be fixed immediately in all affected products.

den4b · 2017-02-05 20:38

This issue has been fixed in ReNamer 6.6.0.6 Beta.

You can download it here:
http://www.den4b.com/downloads/renamer

den4b Forum

#1 2015-03-08 22:31

Date off by 1 hour

#2 2015-03-08 23:34

Re: Date off by 1 hour

#3 2015-03-15 16:24

Re: Date off by 1 hour

#4 2015-03-16 17:59

Re: Date off by 1 hour

#5 2015-03-16 19:12

Re: Date off by 1 hour

#6 2017-01-21 22:47

Re: Date off by 1 hour

#7 2017-01-22 12:49

Re: Date off by 1 hour

#8 2017-02-05 20:38

Re: Date off by 1 hour

Board footer