Eric's suggestion above is the right shape, and the conflicting information you ran into is worth clearing up, because the other route fails in a quiet way.
The entry date on the issue and convertedOpTaskEntryDate on the project are the same timestamp. convertedOpTaskEntryDate is not the moment of conversion, despite the name. It is a copy of the source issue's own entry date, stamped onto the project when the conversion happens. Pair those two and you get zero, every time, with no error to tell you why.
I checked this against a tenant rather than going from the field name: on every converted project sampled, the project's convertedOpTaskEntryDate matched the source issue's entryDate to the millisecond, while the project's own entryDate sat days or weeks later. On unconverted projects both fields come back null, so it is not a general-purpose date being read wrong.
The useful part is that the pair you want sits entirely on the project, so there is no join and no cross-object reference:
DATEDIFF({entryDate},{convertedOpTaskEntryDate})
entryDate on a converted project is the project row's own creation, and on a converted project that creation is the conversion. That is also why Eric's version works, since project entry date really is the conversion moment. One caveat on that half: I confirmed the copied-date behavior directly, but I inferred the "project entry date equals the conversion moment" part from it being the row's creation timestamp, rather than timestamping a live conversion, so sanity-check it against one project whose history you already know.
Also worth knowing if you ever want to report this from the issue side: the issue carries no matching back-reference. The conversion linkage is recorded on the project only, so the report has to start from the project.
This one is in the open-sourced Workfront knowledge base I keep, along with the rest of the field-semantics traps: github.com/Thousand-Cuts/wf-toolkit