Regarding the timestamps, it's almost definitely google's side.
Downloaded multiple versions of the video and compare to their published time, according to the google API.
Original (
API file)
Encoded date: UTC 2014-07-16 19:11:19
<published>2014-07-17T19:11:54.000Z</published>
The mirror from here (
API file)
Encoded date: UTC 2014-07-16 20:19:10
<published>2014-07-17T20:19:44.000Z</published>
Random third (
API file)
Encoded date: UTC 2014-07-16 20:32:12
<published>2014-07-17T20:33:16.000Z</published>
Each encoded date is within a minute of the published date, only out by one day in each case.
Unless each copy of the video (mirrored across various accounts) was encoded specifically a day before it was uploaded, this looks to be a systematic error with youtubes encoding stamps. This is ignoring that the encoder has a specific google video encoder tag that is put into each uploaded video at the time it is encrypted by the google servers.
For shits and giggles I also checked
this BBC video (
API file).
Encoded date: UTC 2014-07-16 17:32:55
<published>2014-07-17T17:29:39.000Z</published>
NB: I downloaded this one at a lower resolution as opposed to the raw file, and I'm assuming this is encoded by the servers after the original has already been published. Still got the day gap there
So the Beeb must have been in on it as well.
But seriously, what sense would it make to have encoded videos a day in advance? So many things that could go wrong with that, especially given it would have had to have been a subtle operation in all other senses (originally uploading and taking down partial videos of just a few phone calls, including rather specific details and timings that could easily be off).