Those servers are out of spec, then. The RFC says it's supposed to be POSIX time, i.e., always in UTC. https://tools.ietf.org/html/rfc1952

Perhaps those servers are running Windows, where the time is local time and the server doesn't want to spend the effort to do the conversion?

The spec predicted in 1996 that this would happen: "(Note that this may cause problems for MS-DOS and other systems that use local rather than Universal time.)"

Are you seriously suggesting Windows doesn't know the concept of UTC time? And secondly suggesting that fiddling with timezone offsets is an expensive conversion?

the system clock on windows is not UTC, it is local time. On Unix the clock is always UTC and is converted to local time for display purposes.

That is the same as Windows. Where are you getting your information?

No, there was a time when Windows stored local time -- also synced to BIOS clock. I don't think that's true anymore, though.

it remains true in windows 10, although it can be changed via some registry fudging.

> Most webservers fill this date field with zeros, about 10% use the actual date, including the timezone

They can't include the timezone since the field is a unix timestamp, there's no room for the timezone.

Apparently the script just assumes whichever date is stored in the mtime field is a local date (when the spec suggests UTC/GMT): https://github.com/jcarlosn/gzip-http-time/blob/master/time....

I think you can blame gzip. Tools shouldn't insert unnecessary metadata into files. At least not without asking or warning. What does putting a timestamp into gzip add? Or the operating system, for that matter?

> What does putting a timestamp into gzip add?

Roundtripping the file's mtime through compression/decompression is convenient. Same reason why the original filename can be stored (roundtrip it in case the filename is truncated at one point e.g. by having the gzip archive move through an msdos system). Here's how the spec defines it:

    MTIME (Modification TIME)
            This gives the most recent modification time of the original
            file being compressed.

Sadly the spec then goes on to recommend leaking the compression date:

            The time is in Unix format, i.e.,
            seconds since 00:00:00 GMT, Jan.  1, 1970.  (Note that this
            may cause problems for MS-DOS and other systems that use
            local rather than Universal time.)  If the compressed data
            did not come from a file, MTIME is set to the time at which
            compression started.  MTIME = 0 means no time stamp is
            available.

However note that the spec recommends a unix timestamp, which is ~UTC, and doesn't include the space for a timezone. Reading the POC[0] it apparently assumes any non-zero mtime is immediate (ignoring cached assets) and local.

[0] https://github.com/jcarlosn/gzip-http-time/blob/master/time....