Looking at src/archive/zip/reader.go from the Go 1.10 kit, I see that readDirectory() gets the modified time from the first 32 bits after an infoZipUnixExtraID's length field:

    case infoZipUnixExtraID:
        if len(fieldBuf) < 4 {
            continue parseExtras
        }
        ts := int64(fieldBuf.uint32()) // ModTime since Unix epoch
        modified = time.Unix(ts, 0)

But according to file unzip60/proginfo/extrafld.txt from
https://sourceforge.net/projects/infozip/files/UnZip%206.x%20%28latest%29/UnZip%206.0/unzip60.tar.gz/download, the layout of an infoZipUnixExtraID extra is:

    0x5855  Short   tag for this extra block type ("UX")
    TSize   Short   total data size for this block
    AcTime  Long    time of last access (GMT/UTC)
    ModTime Long    time of last modification (GMT/UTC)

so the current code gets the last access time, not the last modification time.

In fact, the ModTime field in an infoZipUnixExtraID (0x5855) extra header has the same offset and size at
the ModTime field in an unixExtraID (0x000d) block, so both cases can use the same code:
zip-bug.patch.gz

This is (probably) not an important bug, because the infoZipUnixExtraID (0x5855) block has long been deprecated in favor of extTimeExtraID (0x5455) and the Unix type 2 extra block (0x7855).