weak encryption + streaming does not set local CRC value to zero

[pmqs]

appnote section 4.4.4 says this about the CRC value when streaming is enabled

    Bit 3: If this bit is set, the fields crc-32, compressed 
           size and uncompressed size are set to zero in the 
           local header.  The correct values are put in the 
           data descriptor immediately following the compressed
           data.  (Note: PKZIP version 2.04g for DOS only 
           recognizes this bit for method 8 compression, newer 
           versions of PKZIP recognize this bit for any 
           compression method.)

In practice, if weak encryption is enabled along with streaming, the CRC value is not set to set to zero. Below is from Info-ZIP source code where it sets the CRC value when weak encryption is enabled

        /* Traditional encryption with an extended header implies that
          * we use (the low 16 bits of) the MS-DOS modification time
          * instead of the real (unknown) CRC as the "CRC" for the
          * pseudo-random seed datum.  (The high 16 bits of the "CRC"
          * are used in the Traditional encryption header.)
          *
          * This use of file time as the CRC and then use of a data
          * descriptor to hold the CRC is not standard, but is readable
          * by various utilities out there.  We do it this way to avoid
          * reading a file more than once and to support streaming.

The zipdetails code currently expects the appnote behaviour. That needs to change so that it uses the de-facto standard that is used by the implementations.