I found source code for some other projects handling the same data. They all seem to agree that it should be 1:

- Golang's zip reading code: https://github.com/golang/go/blob/f7ac70a56604033e2b1abc921d3f0f6afc85a7b3/src/archive/zip/reader.go#L536-L538
- A C contrib file with zlib: https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/contrib/minizip/zip.c#L620-L624
- Code from Info-ZIP, which is used by many Linux distros, is a bit less clear, but it has an illuminating comment:

    if ((G.ecrec.number_this_disk != 0xFFFF) &&
        (G.ecrec.number_this_disk != ecloc64_total_disks - 1)) {
      /* Note: For some unknown reason, the developers at PKWARE decided to
         store the "zip64 total disks" value as a counter starting from 1,
         whereas all other "split/span volume" related fields use 0-based
         volume numbers. Sigh... */

So I think you've got an invalid zip file. If it's otherwise valid, there might be a case for Python tolerating that particular mistake. But it's probably better to fix whatever is making the incorrect zip file, because other tools are also going to reject it.