I grabbed some boilerplate off the web to make my systemd timer/service pair work. Worked fine.
ie,
systemctl enable myThing.timer
systemctl enable myThing.service
systemctl start myThing.timer
#do not start myThing. service or it will run immediately, that's ok at some other time for a special non-timer purpose.
Showed a nice schedule with 'status' and it ran correctly at the right time.I did some debugging and experiments to tune the system and, after seeming to work ok, it started telling me that the timer was dead. I could find no reason for a long, harrowing debug session.
Here is the answer.
I had started the process by implementing the timer/service pair pointing at a trivial test script. It ran and quit instantly. I did not notice that it was running and quitting on timer start. I also think that I (incorrectly) did "systemctl start" on the quick test service which then exited normally.
Later, I wired it up to my real process, one that takes more than an hour to execute. Of course, I don't want to wait that long so I did "systemctl stop".
After that, the timer would not work. It said it was dead. I tried everything.
The problem is that the boilerplate I grabbed included a "Requires" statement in the Unit stanza. It was set to the same name (myThing.service) as the target service so I did it too. That was an error. I do not know why the boilerplate author included it but requiring the target.service as a dependency makes no sense even though it basically worked.
When I did systemctl stop the long-running target service, that put it into a state where the dependency was not able to be met. Not entirely sure what the difference between never run and stop is but, I have proven this.
When I removed the extraneous 'Require' statement, that dependency went away, the timer started correctly and all was happiness and unicorns.
What I still don't know (Hey, Smartypants, that's what comments are for) is why stopping the target service made it violate the Require constraint.