正如 Hans Passant 在评论中提到的，zip 文件格式使用 MS-DOS Date & Time 结构。
这个结构被定义为两个独立的unsigned short 值，如下所示：
wFatDate
The MS-DOS date. The date is a packed value with the following format.
Bits Description
0-4 Day of the month (1–31)
5-8 Month (1 = January, 2 = February, and so on)
9-15 Year offset from 1980 (add 1980 to get actual year)
wFatTime
The MS-DOS time. The time is a packed value with the following format.
Bits Description
0-4 Second divided by 2
5-10 Minute (0–59)
11-15 Hour (0–23 on a 24-hour clock)
在创建 MS-DOS 时，这些计算机上还没有使用时区（不过，自 1970 年以来，Unix 就已经有了这个概念。）使用 MS-DOS 的人通常在办公室或家里，而没有使用 MS-DOS。通过计算机与其他国家的人交流，更不用说其他国家了。那时内网也很贵。
创建 zip 文件格式的公司错误地使用了 FAT 文件系统日期格式并卡住了。所以 zip 文件是使用本地时间创建的（不是必须的，但至少这是预期的行为。）
不过，zip 格式提供了添加 extensions（来自发布评论的 @user3342816 的链接）的方法，包括各种时间戳。
0x000a NTFS (Win9x/WinNT FileTimes)
0x000d Unix
NTFS 块是这样描述的：
-PKWARE Win95/WinNT Extra Field:
==============================
The following description covers PKWARE's "NTFS" attributes
"extra" block, introduced with the release of PKZIP 2.50 for
Windows. (Last Revision 20001118)
(Note: At this time the Mtime, Atime and Ctime values may
be used on any WIN32 system.)
[Info-ZIP note: In the current implementations, this field has
a fixed total data size of 32 bytes and is only stored as local
extra field.]
Value Size Description
----- ---- -----------
0x000a Short Tag (NTFS) for this "extra" block type
TSize Short Total Data Size for this block
Reserved Long for future use
Tag1 Short NTFS attribute tag value #1
Size1 Short Size of attribute #1, in bytes
(var.) SubSize1 Attribute #1 data
.
.
.
TagN Short NTFS attribute tag value #N
SizeN Short Size of attribute #N, in bytes
(var.) SubSize1 Attribute #N data
For NTFS, values for Tag1 through TagN are as follows:
(currently only one set of attributes is defined for NTFS)
Tag Size Description
----- ---- -----------
0x0001 2 bytes Tag for attribute #1
Size1 2 bytes Size of attribute #1, in bytes (24)
Mtime 8 bytes 64-bit NTFS file last modification time
Atime 8 bytes 64-bit NTFS file last access time
Ctime 8 bytes 64-bit NTFS file creation time
The total length for this block is 28 bytes, resulting in a
fixed size value of 32 for the TSize field of the NTFS block.
The NTFS filetimes are 64-bit unsigned integers, stored in Intel
(least significant byte first) byte order. They determine the
number of 1.0E-07 seconds (1/10th microseconds!) past WinNT "epoch",
which is "01-Jan-1601 00:00:00 UTC".
Unix 块也包括两个时间戳：
-PKWARE Unix Extra Field:
========================
The following is the layout of PKWARE's Unix "extra" block.
It was introduced with the release of PKZIP for Unix 2.50.
Note: all fields are stored in Intel low-byte/high-byte order.
(Last Revision 19980901)
This field has a minimum data size of 12 bytes and is only stored
as local extra field.
Value Size Description
----- ---- -----------
0x000d Short Tag (Unix0) for this "extra" block type
TSize Short Total Data Size for this block
AcTime Long time of last access (UTC/GMT)
ModTime Long time of last modification (UTC/GMT)
UID Short Unix user ID
GID Short Unix group ID
(var) variable Variable length data field
The variable length data field will contain file type
specific data. Currently the only values allowed are
the original "linked to" file names for hard or symbolic
links, and the major and minor device node numbers for
character and block device nodes. Since device nodes
cannot be either symbolic or hard links, only one set of
variable length data is stored. Link files will have the
name of the original file stored. This name is NOT NULL
terminated. Its size can be determined by checking TSize -
12. Device entries will have eight bytes stored as two 4
byte entries (in little-endian format). The first entry
will be the major device number, and the second the minor
device number.
[Info-ZIP note: The fixed part of this field has the same layout as
Info-ZIP's abandoned "Unix1 timestamps & owner ID info" extra field;
only the two tag bytes are different.]
正如我们所见，NTFS 和 Unix 块清楚地将它们的时间戳定义为使用 UTC。 NTFS 日期比 Unix 时间戳 (1s) 具有更高的精度 (100ms)，由于它使用 64 位，它的生存时间也更长（有关 32 位时间戳的更多详细信息，请参阅Year 2038 Problem）。