Multi-Rename Tool:Date and Time

Here you can propose new features, make suggestions etc.

Moderators: white, Hacker, petermad, Stefan2

User avatar
kiwerry
Junior Member
Junior Member
Posts: 16
Joined: 2011-04-03, 12:54 UTC
Location: Dresden, Germany

Multi-Rename Tool:Date and Time

Post by *kiwerry »

Please enhance the multi-rename tool so as to allow the user to change the date and time of a file, not just the name.
Why?
Example: Image files copied from a camera or smartphone to a PC are often given the date and time at which they were copied, rather than the original date (usually the creation date) they had in the system of the camera/smartphone. This usually depends on the software which is used to do the copying.

It is already possible to use the multi-rename tool to change the filename by incorporating the system date ([YMD]) or the exif creation date in the filename. It would be a really useful enhancement to be able to change the files' system date and time to the creation date and time. That there is a need for this is evidenced by the plethora of questions on how the change a file's date and time to the date and time the at which the picture was taken.

There are tools out there that can do this - exiftool comes to mind - but they tend to have a steep earning curve and are often designed to accomplish much more than meet this simple need. A sledgehammer will also crack a nut.
User avatar
Gral
Power Member
Power Member
Posts: 1460
Joined: 2005-01-26, 15:12 UTC

Re: Multi-Rename Tool:Date and Time

Post by *Gral »

Already possible with "Change attributes" dialog window: Files - Change Attributes..."
Fla$her
Power Member
Power Member
Posts: 2244
Joined: 2020-01-18, 04:03 UTC

Re: Multi-Rename Tool:Date and Time

Post by *Fla$her »

2kiwerry
Then will be have to rename the dialog. The author is unlikely to do this, especially since the "Changes attributes" dialog with jpg-comment allows it.
And exiftool is not the only tool for this.
Overquoting is evil! πŸ‘Ž
HalbschuhTouri
Junior Member
Junior Member
Posts: 61
Joined: 2023-01-20, 09:33 UTC

Re: Multi-Rename Tool:Date and Time

Post by *HalbschuhTouri »

True, this can be done in "Change attributes". But still I would support the suggestion to also making this option available via the MRT.

After all the MRT is the place-to-be for more complex and systematic renaming efforts, in particular for multiple files. And among all the other possibilities in there also being able to manipulating the file-date from this central location would be a nice and welcome addition.

support++
Fla$her
Power Member
Power Member
Posts: 2244
Joined: 2020-01-18, 04:03 UTC

Re: Multi-Rename Tool:Date and Time

Post by *Fla$her »

HalbschuhTouri wrote: ↑2023-01-20, 09:55 UTCin particular for multiple files.
The attributes dialog also works with a group of files, if that's what you're talking about.

It is more logical to request an extension of the functionality of the attributes dialog than to add it to a dialog that is not intended for this.
Overquoting is evil! πŸ‘Ž
User avatar
jinsight
Senior Member
Senior Member
Posts: 299
Joined: 2003-02-25, 19:47 UTC
Location: Wooster, Ohio, USA

Re: Multi-Rename Tool:Date and Time

Post by *jinsight »

Support the suggestion to also making this option available via the MRT.

support++
License #1945
Windows 10 Pro x64
Version 22H2 (OS Build 19045.3930)
TC 11.00 x64 and x86, Everything 1.5.0.1366a x64, QAP 11.6.3.1 x64
HalbschuhTouri
Junior Member
Junior Member
Posts: 61
Joined: 2023-01-20, 09:33 UTC

Re: Multi-Rename Tool:Date and Time

Post by *HalbschuhTouri »

Fla$her wrote: ↑2023-01-20, 13:02 UTCThe attributes dialog also works with a group of files, if that's what you're talking about.

It is more logical to request an extension of the functionality of the attributes dialog than to add it to a dialog that is not intended for this.
I still beg to differ. From a strictly logical point of view changing file-dates is somewhat "out-of-place" in a section which mainly deals with attributes to begin with. So don't get me wrong - it's nice to have this option there if it cannot be found somewhere else in a more appropriate place - but changing the file-date certainly is more of a renaming-matter than one of dealing with attributes.

And what if - if for some reason one would like to apply the very same file-date to a corresponding group of files, perhaps with the intention of grouping them together and finding them as a group later on - but then for better distinction would like to add a counter to their names? Where would such an operation best be home to? You guessed it! The MRT.
Fla$her
Power Member
Power Member
Posts: 2244
Joined: 2020-01-18, 04:03 UTC

Re: Multi-Rename Tool:Date and Time

Post by *Fla$her »

HalbschuhTouri wrote: ↑2023-01-21, 06:53 UTCFrom a strictly logical point of view changing file-dates is somewhat "out-of-place" in a section which mainly deals with attributes to begin with.
I understand that the attributes themselves are a separate type of metadata. But it just so happened that in most attribute change programs (this also applies to other file managers), the date change function is enabled. Based on the current functionality of the dialog, it would make sense to rename it to "Change Metadata", then there would be no disagreement.
But correcting metadata cannot relate to renaming files in any way. The key word here is "name".
HalbschuhTouri wrote: ↑2023-01-21, 06:53 UTCYou guessed it! The MRT.
Alas, but I do not find a connection between setting the date and adding a counter.
Overquoting is evil! πŸ‘Ž
HalbschuhTouri
Junior Member
Junior Member
Posts: 61
Joined: 2023-01-20, 09:33 UTC

Re: Multi-Rename Tool:Date and Time

Post by *HalbschuhTouri »

Fla$her wrote: ↑2023-01-21, 09:07 UTCAlas, but I do not find a connection between setting the date and adding a counter.
Well, I do. Think of it this way. Let's assume we're managing a national array of weather-data-stations. Each station will issue an automated hourly report of data like temperature and so on. Of course for technical reasons those reports come in with slightly different time-stamps (varying somewhat around the full hour).

Now for publication we would like to set all time-stamps exactly to the full hour while at the same time we'd like to rename the internal names of those data-sets to somewhat more meaningful like expressing the geographical location in clear words and adding (not unlike a counter) the full hour to which these data-sets correspond.

So nobody can deny this whole endeavour would be best and comprehensively dealt with in a centralized location/dialogue - which happens to be the MRT - and certainly not some renamed "change metadata"-dialogue as the main purpose would be to "attribute" (in a semantical, not a technical sense) more meaningful plain language names to the data-sets for publication.
Fla$her
Power Member
Power Member
Posts: 2244
Joined: 2020-01-18, 04:03 UTC

Re: Multi-Rename Tool:Date and Time

Post by *Fla$her »

2HalbschuhTouri
The need for simultaneous processing is understandable, but specific. And in this case, it is not possible in one pass in the context of the current interface, since the same options cannot be used for two different operations at the same time. And you haven't offered any other interface yet. In fact, will be have to duplicate all the options and create an additional two columns of results, and there is simply not enough space for this.
And for sequential processing, an additional combobox is required here, which will allow switching between data types (name and other supported metadata, including on the basis of some content plugins).
Overquoting is evil! πŸ‘Ž
HalbschuhTouri
Junior Member
Junior Member
Posts: 61
Joined: 2023-01-20, 09:33 UTC

Re: Multi-Rename Tool:Date and Time

Post by *HalbschuhTouri »

Fla$her wrote: ↑2023-01-21, 18:02 UTC The need for simultaneous processing is understandable, but specific. And in this case, it is not possible in one pass in the context of the current interface, since the same options cannot be used for two different operations at the same time.
Objection. Except for adjusting the date/time the renaming CAN be done in a single pass, even now with the current interface, as e.g. applying a counter to those names would make sure no identical names could result from renaming and there could also other precautions be taken to guarantee each new file-name would be unique thereafter (for instance adding some unique numbering of the original data-sets at the end of each file-name).

Of course, having all that done, one could (and currently must) change to the "Change Attributes"-section with all new file-names selected and change the date/time from there. But it would sure be a matter of convenience also being able to include that time-adjustment-step into the single-pass-renaming-step performed from within the MRT.

No one claims that some particular operation ought only to be done from one singular location (as you seemingly would imply). The whole MRT could be called redundant in some way as all file-names can also be directly altered from the left or right file-panel. And still the MRT is an extremely valuable and much more comprehensive "one-stop-shop" for group-wise renaming, IMHO one of the most powerful tools within the entire TC-environment. So I really can't see any valid reason for not further enhancing its versatility by adding a date/time-manipulating-option to it as well.
Fla$her
Power Member
Power Member
Posts: 2244
Joined: 2020-01-18, 04:03 UTC

Re: Multi-Rename Tool:Date and Time

Post by *Fla$her »

HalbschuhTouri wrote: ↑2023-01-21, 18:50 UTC
Fla$her wrote: ↑2023-01-21, 18:02 UTCAnd in this case, it is not possible in one pass in the context of the current interface, since the same options cannot be used for two different operations at the same time.
Objection. Except for adjusting the date/time the renaming CAN be done in a single pass
The objection is not accepted. There is no point in talking about one pass for only one operation (renaming). It was about two (or more) operations.
And I don't see any point in sticking only to standard dates. No one has canceled other metadata.
Overquoting is evil! πŸ‘Ž
HalbschuhTouri
Junior Member
Junior Member
Posts: 61
Joined: 2023-01-20, 09:33 UTC

Re: Multi-Rename Tool:Date and Time

Post by *HalbschuhTouri »

Fla$her wrote: ↑2023-01-21, 19:16 UTC There is no point in talking about one pass for only one operation (renaming). It was about two (or more) operations.
You seemingly don't (want to?) understand. What I'm talking about is renaming multiple (dozens of) data-sets/files to unique new (hopefully more meaningful to the reader) systematic (following some succinct naming-convention) file-names in a single pass and (after the proposed future enhancement) at the same time standardizing their time-stamps to the full hour, all from a single "one-stop-shop"-MRT-operation. It's not all that hard to comprehend. :wink:
Fla$her
Power Member
Power Member
Posts: 2244
Joined: 2020-01-18, 04:03 UTC

Re: Multi-Rename Tool:Date and Time

Post by *Fla$her »

2HalbschuhTouri
I don't know what "standardizing their time-stamps to the full hour" is, but I understood kiberry's request perfectly. If you want something different, then let me know.
Overquoting is evil! πŸ‘Ž
HalbschuhTouri
Junior Member
Junior Member
Posts: 61
Joined: 2023-01-20, 09:33 UTC

Re: Multi-Rename Tool:Date and Time

Post by *HalbschuhTouri »

Fla$her wrote: ↑2023-01-21, 20:06 UTC I don't know what "standardizing their time-stamps to the full hour" is, but I understood kiberry's request perfectly. If you want something different, then let me know.
So did I and contrary to your apparent reservations and objections I fully support his proposal. He gave us some valid examples about camera/exposure-data where such an enhanced-functionality-MRT could be successfully applied to handle those. And in my subsequent example I just tried to complement the scope of applications where such a functionality would come in quite handily indeed.

No clue what might be that difficult to understand about the term "standardizing their time-stamps to the full hour". If for instance temperature-measurements were triggered at exactly - say 09:00 in the morning - at various monitoring-stations distributed across the country but for slightly different processing- and transmission-speeds will actually (as a report-file) be generated between - say 9:00:30 and 9:02:45 - then all those report-file-time-stamps should be adjusted/standardized to the actual time-of-physical-measurement (09:00:00 sharp) rather than to some random-delay-time-stamp caused by different data-processing-speeds thereafter and therefore resulting in slightly different time-stamps at which those report-files may actually have been (electronically) written/generated in the end.
Post Reply