Date/time bugs

Advanced Renamer forum
#1 : 22/03-12 17:26
John Clement
John Clement
Posts: 5
I have been having the problem that setting the timestamp for creation or modification is off by 1 hour. Similarly using the timestamp to change the file name is off by 1 hour in the other direction. This may be related to daylight savings time in Windows 7.

In addition I have had difficulty with the timestamp in a batch where several commands were done in a row.
1. Set the timestamp from the information in the name.
2. Adjust the timestamp by an offset
3. insert timestamp info into the name

The first time I would execute it, it didnt't work for a given file. But then put the file back and it worked. It appears that the first time sets the timestamp, and the second time adjusts it and puts it into the name.

However if I separate the steps and do them one at a time, I can get it to work reliably.

It is good that the Exif data can be used, but I have also noticed a 1 hour offset when using it to change the filename, again possibly daylight savings problems. But I would like to be be abe to change it such as the Date taken, the copyright, and the author. In particular an option on the timestamp method to change the Exif timestamp would be super.

This would be VERY helpful for maintaining the Exif information while using editors that do not handle it correctly, or translation between formats that do not have these fields.


22/03-12 17:26
#2 : 22/03-12 20:16
Kim Jensen
Kim Jensen
Administrator
Posts: 771
Reply to #1:
I have had this request before. The use of timestamps needs some work. I will take a look at it at some convenient time. Also as I remember, timestamp changes are not revertable.
I think the 1 hour off issue is due to some dayligt savings time configuration. What time zone are you in?


22/03-12 20:16
#3 : 24/03-12 23:30
John Clement
John Clement
Posts: 5
Reply to #2:
I am in US Central time. Which is currently on daylight time. I was translating a time to Thailand which is currently on standard time. That is my camera was recording times in central daylight but the pictures were taken in Thailand so I needed to translate to the Thai time. I had put the date-time taken into the filename yy-mm-dd hr;mn;ss. When I put the encoded time in the file name into the modification time, it changed by 1 hour. The delta time change worked as one would expect. But then when I put the modification time into the file name there was a 1 hour change in the reverse direction. So the end result was the correct encoding in the file name.

I do this so the pictures will be automatically in order. I could use the date taken, but that is often wiped out by various programs and not supported in all formats. It is a jungle!!!

Perhaps variables for storing various date times when making translations would provide a fix. In other words when a date-time is referenced or changed also keep it in a variable. Then the next command that references it would use the value in the variable rather than the value in the file. It may be that when you do the next operation in a string that the previous one has not been finished. I don't know if this has anything to do with the fact that I have a dual processor. Pr perhaps a check for completion is necessary.


24/03-12 23:30
#4 : 26/03-12 08:26
Kim Jensen
Kim Jensen
Administrator
Posts: 771
Reply to #3:
When timestamps methods and naming methods in the same batch you won't always get the result you expect. I will make sure it will get fixed in a later release. I am working on adding unicode support to Advanced Renamer so it might take a little while until I get to fixing this.


26/03-12 08:26
#5 : 28/03-12 16:17
John Clement
John Clement
Posts: 5
Reply to #4:
The time offset was found by doing the process one step at a time and not by putting them into the same batch. When I put the steps together as one batch nothing worked properly. Essentially the first time I ran it nothing seemed to happen, but the second time, it worked. I found that the first time changed the modification date, but that did not transfer to the file name. The second time picked up the modified date and transferred it.

Hooray for getting unicode to work. Ant renamer has had that for a long time, but it is not as versatile as your program, and it messes up sometimes when using the EXIF date taken to change the file name. It also does not have multiple level undo, but it has a much simpler interface.

A nice enhancement to your interface might be to have a button which puts back the list of files used in the last batch. This is not an undo, but rather a means for getting the same files back for subsequent changes. Ant keeps the list of files which sometimes causes problems if you forget to clear it when changing other files, so the current behavior is probably better. Ant development is dead.

Some well know commercial programs such as some MAGIX products still can't handle unicode, and sadly Karenware gags on it. Since Karen is deceased her wonderful programs may never be updated. They are available in source for the venturesome.


28/03-12 16:17
#6 : 29/03-12 08:56
Kim Jensen
Kim Jensen
Administrator
Posts: 771
Reply to #5:
It is actually going fine with the unicode conversion. That biggest problems arise when dealing with resources in files. By resources I mean ID3 tags in MP3 files, some Exif information in image files, and information in video files. I was afraid all the wonderful translations people have submitted were no longer usable, but they still work!! Some visual errors seen by people using more obscure (obscure to me) alphabets are also fixed with the unicode support.

Advanced Renamer already have a button for adding the renamed or non-renamed files to the list again. After the rename you will see a result-box in the lower right corner of the program. In that box you have the option of adding the files again.


29/03-12 08:56
#7 : 02/04-12 17:14
John Clement
John Clement
Posts: 5
Reply to #6:
Thank you for the info about reloading. I might have missed it in the docs.


02/04-12 17:14