Probably not. I suspect this is a confusion based on the free-running microsecond counter of the gateway concentrator chip, which is what the server uses to time downlink replies. It does not measure the time “since” a previous packet as that would break in the case of backhaul packet loss, it is merely a local counter stamp. And it’s the same thing a gateway normally sends when backhaul is live.
It does indeed take some doing to convert it into an actual time - you have to have a sample of both at at point in the same run of the same packet forwarder program, and enough sense of the time to know how many times it has rolled over. And if the concentrator / packet forwarder have been restarted, that breaks the meaning of the counter unless you have a record of the value right before the restart. Uplink frame counts may make as much sense.
But this is also why someone who really wants a packet backup on the gateway should probably write their own. Including an RTC time is quite simple (and yes, if you’re going to this trouble you want a battery backed RTC and not a situation where you only have time after you can connect to an NTP server).
If you’re really stuck, put an RTC in a node and have it announce the time (doesn’t have to be right, just and monotonic) and use that as a time standard to measure other nodes’ packets by.