documentation components in a generated ZIP site bundle have a timestamp of 1980-00-00 00:00
Using Antora v2.0.1 if you generate a ZIP (using the "archive" site publishing provider), then the files and directories of each documentation component will have a timestamp of 1980-00-00 00:00.
This is a problem with deployment solutions that consider only the timestamp and filesize of the files while they decide whether or not the file has changed since the previous deployment.
The deployment solution of Azure's App Services does this by default. It uses KuduSync for deployment to linux App Services and KuduSync.NET for Windows based App Services. The linux/NodeJS variant compares timestamp and filesize, while the .NET variant only compares the timestamps of old vs. new files to detect changes (this is meant as a performance optimization to speed up deployment). There's a commandline option for KuduSync.NET to do a full SHA-1 hash based check, but it's buggy, because it only considers this possibility if the timestamps are already different.
Using Antora's ZIP site publisher provider and generated ZIP cannot be reliably deployed to Azure's App Service. The workaround for now is to use the "fs" site publisher provider and create the ZIP with a separete utility.