@BetterRed You are correct, of course; I am speaking of filesystem dates. I'm afraid I was being too clumsy with my language
From your initial reply, I began to glean that the feature I wanted was less likely present than I had initially hoped; and you've confirmed that. Thanks for clarifying this.
@kacir Thanks for the detailed and informative reply! From both answers, it seems pretty clear that I will have to script things. I had considered your approach as one of two if calibre couldn't do this natively. Perhaps you would be kind enough to advise me which would be better. I have about 10000 files, so I'll probably write a Perl script to manage the process either way.
1. As you say, embed the date in the filename. I appreciate the guidance, and don't see this as being a problem. This approach has the advantage of being easy and unintrusive regarding the metadata.db itself. However, it seems a bit unnatural because the files themselves (the ones managed by calibre) would still lose their timestamps. If for some reason I need that info down the road, I'll have to reconstruct it from the db or hope I have an original copy of the files floating about.
2. Alterately, I could edit the db. I would add the files to calibre as is, and then do two things (to clarify, the 2nd approach involves doing both):
(a) Run a SQL query to modify the "Date/timestamp" and/or "Published/pubdate" fields (or just add custom fields for the filesystem ctime and mtime and populate those). I also can directly modify the "modified" date by this approach regardless of its ro status in calibre.
(b) Using "touch -r $orig_file $calibre_copy_of_file", change the dates of the files themselves under calibre's management.
This 2nd approach requires a little finesse because my files are in multiple subdirectories (I add them using the "include subdirectories" option) -- so there may be recycled filenames. I probably would have to use an md5 checksum to match files instead, but this isn't a big deal. While this approach seems a bit more intrusive and involved, it has the advantage that -- if done right -- in the end the world will look to calibre just as it does to the filesystem itself. The files will seem as if they had been added one by one at the time of their (filesystem) creation, and last modified at the time of their last filesystem modification.
My inclination is to use (2) even though it is more complicated. In your opinion, is this a big mistake? My concern is that there are hidden dates in the calibre db (or in some config file I don't know about) that would blow everything up when it performs consistency checks. Then calibre would either fail or overwrite my dates with its own "corrected" ones. Of course, I could try (2) and then revert to (1) if it fails -- but it would definitely be useful to know at the outset whether it is a bad idea altogether. If you have any insight into whether I'm setting myself up for a world of hurt, I'd really appreciate it.
I should clarify that I don't mind a bit of unix scripting (including SQL queries). I'm ok with Perl and already have had to write scripts to OCR and process these scanned documents in bulk as part of my bigger project to manage my scanned bills, so an extra script is ok if it is necessary and will work.
I really appreciate your advice and help!
Cheers,
Ken