TL;DR: no manual setting of stuff for each descriptor.
Here's what I'm playing around with:
I want to create "properly" a watch-only wallet of Satoshi/Patoshi blocks (see
http://satoshiblocks.info) including genesis block. I made one with Electrum but it's not "satisfying" as a SPV wallet doesn't see the P2PK coinbase outputs (or any P2PK outputs, I guess). So, Electrum or similar wallets aren't suitable for this.
Rescue comes in the form of "combo(PK)#checksum" descriptors, available in Bitcoin Core which "see" any standard output script for Public Key PK. Thus filling an empty descriptor wallet with appropriate combo(PK) descriptors would give me what I'm looking for. Together with the genesis block that's 21954 unique descriptors. bitcoin-cli doesn't like e.g. if I try to add 1000 descriptors at once with command
importdescriptors. 500 seems to work but gets slower and slower. Not quite sure what the bottleneck is (Bitcoin Core chewing on some database or my HDD storage of wallet and blockchain or both).
I wrote a script that iterates over the block heights of those 21954 blocks which constructs multiple "requests" of 500 combo()-descriptors. The request string is fed into
bitcoin-cli importdescriptors "request". A single descriptor request entry consists of "desc", "timestamp" and "label". [For labels I use zero padded block heights of length 5 except for "Genesis" for block #0 and "Satoshi" for block #9]
In my first try (with buggy script, lol, but the bug(s) didn't yet show up as I didn't get to the final blocks, I'm no professional programmer or scripter...) I didn't care about "timestamp" and set it simply to zero. But that had the side effect that I needed to cancel every blockchain rescan which got fired up by importdescriptors. A spare computer with a HDD as storage device for the blockchain isn't the fastest choice here. Well, that was a pita as every import of a descriptors batch took a lot of minutes before even the rescan started and cancelling the rescan took sometimes even longer before importdescriptors "finished". The manual intervention needed (I had bitcoin-core.QT open on my Linux desktop) wasn't quite what I was looking for.
That's when the hint with "timestamp":"now" came from @achow101.
I created a new empty descriptor wallet and tried again with "timestamp":"now" and rescans finished at the beginning quite fast, but then again some "internal delays" of
importdescriptors emerged and made the (revised and debugged) script not a fire and forget (until finished) thing. Not sure what went wrong, likely my mistake when I had to interrupt the script when some error showed up as bitcoind didn't respond at some point, but I got through with all descriptors. Unfortunately the wallet showed some rather strange and unexpected transactions. Something must have gone wrong as somehow a wrong block and descriptor slipped in.
Because of that I've thrown the wallet of the second experiment away and am up on a rewrite of my script to separate data fetching and import of descriptors. I don't recall that you can remove imported descriptors from a wallet, maybe I've overseen this if some command exists for removal.
My next goal is to fetch all blockchain data via bitcoin-cli (before I "abused" an API call to my Bitcoin Explorer on my RPi Umbrel box that I run to play a little with Umbrel; Umbrel isn't my main node box (RaspiBlitz instead)) and try again with "timestamp":"now" for every descriptor while compiling the data with more care or avoiding hickups that might screw up the import for whatever reason.
I hope a final full blockchain rescan will then bring up all transactions of all descriptors. If this works out: good. If not, well, well, ...
Last resort would be to fetch the block time from the blockchain for every coinbase transaction descriptor and go on with that. Not really sure if and what difference this would make, though. But I'm not going to do this on a HDD as storage device. This screams for a SSD which has much faster seek and transfer time. I don't like to torture my poor small HDD with such experiments. A HDD as main storage device already feels like pain and suffering when you're used to SSDs.