The packaging guidelines request that maintainers preserve the timestamps on downloaded files: https://fedoraproject.org/wiki/Packaging:Guidelines#Timestamps It doesn't seem that rpmspectool does this, though to be fair, the classic spectool doesn't do this either.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Sorry for getting back so late. I've just looked into this, and rpmspectool should write out downloaded files with timestamps preserved, if the server submits the relevant headers: --- 8< --- rpmspectool/download.py --- ... def download(url, where=None, dry_run=False, insecure=False, force=False): ... ts = c.getinfo(c.INFO_FILETIME) ... # set file modification time if ts != -1: os.utime(fpath, (time.time(), ts)) ... --- >8 ------------------------------- I've just tested this with the gimp spec file which has: Source0: http://download.gimp.org/pub/gimp/v%{binver}/gimp-%{version}%{dashprerel}.tar.bz2 This evaluates to: Source0: http://download.gimp.org/pub/gimp/v2.8/gimp-2.8.18.tar.bz2 Here's the timestamp (UTC) of the file from http://download.gimp.org/pub/gimp/v2.8/: gimp-2.8.18.tar.bz2 13-Jul-2016 20:44 20M And here's the file rpmspectool downloaded: nils@gibraltar:/tmp> rpmspectool get ~/devel/git/fedora/gimp/*spec Downloading 'http://download.gimp.org/pub/gimp/v2.8/gimp-2.8.18.tar.bz2' to '/tmp/gimp-2.8.18.tar.bz2' nils@gibraltar:/tmp> TZ=UTC ls -l gimp-2.8.18.tar.bz2 -rw-rw-r--. 1 nils nils 20824198 Jul 13 20:44 gimp-2.8.18.tar.bz2 Do you have a spec file/URL that reproduces the behavior your described?
I've slept a couple of times since I filed this, so honestly I can't even pull together enough context to have even a guess at what I had tested. And of course I should have at least pasted in an example or, well, anything useful. If only for my own sanity. It certainly does seem that the code is there. I wouldn't be surprised if I had seen some issue relating to a server which simply didn't provide the timestamp informationr. In any case, I'm thinking it's best to just close notabug, but I'll leave that to you to ensure I don't foul up any process you might have.
I've just checked that with an FTP URL, wasn't sure if that needed to be handled differently, but the files got downloaded with the correct timestamps, too. I'll close this one.