This comment was correct until commit adf1f98f

, when the `GTimeVal`
which the result was put into (introducing the Y2038-unsafety) was
dropped.

The adjustment and scaling of the `FILETIME` should not make it
Y2038-unsafe: the maximum `FILETIME` is 2^64-1. Subtracting the epoch
adjustment and dividing by 10 gives the timestamp 1833029933770955161,
which is in June 58086408216 (at just after 3am UTC). I think that’s
enough time to be going on with.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #1438