TL:DR, the w32time service will sometimes try to bootstrap the clock with data from TLS handshakes. TLS 1.0-1.2 use a random value in Client Hello/Server Hello which was originaly specified as a uint32 gmt_unix_time plus 28 random bytes. It's better [1] to fill the whole structure with 32 bytes of random data (and TLS 1.3 specifies it without reference to time). If you interpret the random data as a unix time, sometimes you're going to get weird results. It's not clear to me what servers w32time probes to get these values, either.
I've seen other services that use https to bootstrap time in case other clocks are unavailable or suspect (or use a limited expiration certificate to authenticate!), it's a bit difficult because you have to ignore or postpone checking certificate expiration when validating the x.509 certificates, parse the http date header, and then presumably check that the date provided is within the time the certificates involved are valid.
I've seen other services that use https to bootstrap time in case other clocks are unavailable or suspect (or use a limited expiration certificate to authenticate!), it's a bit difficult because you have to ignore or postpone checking certificate expiration when validating the x.509 certificates, parse the http date header, and then presumably check that the date provided is within the time the certificates involved are valid.
[1] https://datatracker.ietf.org/doc/html/draft-mathewson-no-gmt...