Packaging produces inconsistent timestamps between info files and release XML

I’ve invested more time in trying to understand this.

It appears that the update.compare.inc module is doomed to provide incorrect status with the information that it has available.

I use git cloning to install contrib modules onto my development website. That means that the module.info.yml files have neither version nor datestamp keys. In that case, the git_deploy module attempts to fill in the gap by examining the date of the most recent git log entry. When on a dev branch, this means that the date of the installed module is assumed to be the date and time that the most recent commit associated with the installed module.

When checking drupal.org product information to see if a contrib module is current, a request is made to http://updates.drupal.org/release-history/module... to retrieve xml information about the module. The date is extracted from the information about each release. This date appears to be the date and time when the module files on drupal.org are saved (example: http://ftp.drupal.org/files/projects/examples-8.x-1.x-dev.tar.gz). The code in update.compare.inc assumes that this will be done within 100 seconds of the datestamp of the most recent commit. This is just not true. In two cases that I chased down, one was 187 seconds later and another was 16,777 seconds later. The date of the most recent commit is not tightly associated with the file save date of the contrib modules on drupal.org

This is not just an issue if git_deploy is used. I downloaded the most recent examples module and examined the datestamp included in the examples.info.yml file. It was datestamped 1,260 seconds later than what was returned from http://updates.drupal.org/release-history/examples... so it still would have been given a status of UPDATE_NOT_CURRENT.

The problem is that there is no good way for update.compare.inc (or git_deploy) to determine if a contrib module is current.

The only solution would be for http://updates.drupal.org/release-history to return something that would be consistent from all sides. Possibly the datestamp of the commit associated with the file generation. That identical datestamp would also need to be included in the module.info.yml file. A key “commit_datestamp” could be used. The git_deploy module would also be capable of extracting the identical datestamp.

To fix this issue, it is likely that both drupal.org and drupal core would require coordinated changes. But I agree that it probably begins with drupal.org.