Reputation: 1638
I've stumbled across a very unexpected issue, which is that I'm trying to download a file from a NodeJS server from Rust only if the destination file is older than the source. The mtime for the Source file is given by NodeJS using the
let mtime = await source.stat()
.then(stat => stat.mtime.getTime());
which is serialised into JSON along with some other data, and deserialised by Serde on the other end. Note that this value is and stays an integer, and has no consideration for timezones etc.
The receiving end looks like this:
#[derive(Deserialize)]
struct Event {
// ..
mtime: u64
}
// ..
async fn download(event: Event) {
if let Ok(meta) = dest.metadata().await {
let source_mtime = event.mtime.duration_since(UNIX_EPOCH)?.as_millis();
let dest_mtime = meta.modified()?.duration_since(UNIX_EPOCH)?.as_millis();
if source_mtime > dest_mtime {
// download
}
}
}
However, when I print out the two mtime values in Rust (source_mtime
, dest_mtime
), the two values are off by 1 686 675 098 702 which seems a bit much for files which were created within the same week. I then repeated the experiment after touch
ing the source file, and ensuring the mtime was updated too, to find the same amount of discrepancy.
I'm aware of system time drift, and that this may be a source of errors, but to be off by a quadrillion seems a bit excessive. (That's a difference of ~53 years)
If anyone has any insight as to what causes this and/or whether this is just a silly mistake on my end, I'd love to hear it.
Best, JCake
As per @isaactfa's comment, below is a endianness test:
[
<Buffer 96 0d 2d 3a 89 01 00 00>,
<Buffer 2b 4c f1 74 12 03 00 00>,
<Buffer 00 00 01 89 3a 2d 0d 96>,
<Buffer 00 00 03 12 74 f1 4c 2b>
]
As you can see, the values are not remotely similar, even with the byte-order swapped.
A good suggestion, but no cigar...
Upvotes: 0
Views: 44