Today I noticed that files extracted from an APK file all have a modification date time of January 1, 1981 1:01.

output

Actually, including seconds, it is January 1, 1981 1:01:02.

brenton@Brentons-Pieces-M3-MacBook-Pro spacehockey % ls -alT app/build/outputs/apk/release/app-release/ 
total 2944
drwx------@  14 brenton  staff      448 Feb 23 16:20:36 2026 .
drwxr-xr-x@   7 brenton  staff      224 Feb 23 16:19:43 2026 ..
-rw-r--r--@   1 brenton  staff     6148 Feb 23 16:20:36 2026 .DS_Store
-rw-rw-r--    1 brenton  staff    10572 Jan  1 01:01:02 1981 AndroidManifest.xml
drwxr-xr-x   25 brenton  staff      800 Feb 23 16:19:43 2026 assets
-rw-r--r--    1 brenton  staff  1342700 Jan  1 01:01:02 1981 classes.dex
-rw-rw-r--    1 brenton  staff     1738 Jan  1 01:01:02 1981 DebugProbesKt.bin
drwxr-xr-x    3 brenton  staff       96 Feb 23 16:19:43 2026 google
drwxr-xr-x    3 brenton  staff       96 Feb 23 16:19:43 2026 io
drwxr-xr-x    9 brenton  staff      288 Feb 23 16:19:43 2026 kotlin
drwxr-xr-x    6 brenton  staff      192 Feb 23 16:19:43 2026 lib
drwxr-xr-x   44 brenton  staff     1408 Feb 23 16:19:43 2026 META-INF
drwxr-xr-x  266 brenton  staff     8512 Feb 23 16:19:43 2026 res
-rw-rw-r--    1 brenton  staff   138724 Jan  1 01:01:02 1981 resources.arsc

That is a peculiar date time! I can imagine that the tooling for APK files would want to timestamp all files with a consistent date time for security and build reproducibility. And I can even imagine that filling all fields (year, month, day) and (hour, minute, second) with 1 would be a good date time to use.

But the second value is 2 and not 1. What is going on?

After some searching, I found this issue:

Incorrect timestamp when unzipping universal apk

The comments in that issue confirm that this is intentional behavior, but the question remains: why this particular date time?

I looked through the sources of bundletool and found this line:

private static final long ZIPFLINGER_ZIP_TIMESTAMP = 347158862000L;

January 1, 1981 1:01:02 is 347158862 seconds since January 1, 1970.

Fine. So it seems like something called ZipFlinger is doing the actual timestamping of files in the APK and that is where January 1, 1981 1:01:02 is coming from.

More searching. Find Zipflinger.

From the docs:

Zipflinger is a library dedicated to ZIP files manipulation. It can create an archive from scratch but also add/remove entries without decompressing/compressing the whole archive.

Looking through the sources for Zipflinger, I find:

// JDK 9 consider time&data field with value 0 as invalid. Use 1 instead.
// These are in MS-DOS 16-bit format. For actual specs, see:
// https://msdn.microsoft.com/en-us/library/windows/desktop/ms724247(v=vs.85).aspx
public static final short DEFAULT_TIME = 1 | 1 << 5 | 1 << 11;
public static final short DEFAULT_DATE = 1 | 1 << 5 | 1 << 9;

Aha!

The date and time values are 16-bit shorts that set 1 bits at particular locations.

What is MS-DOS 16-bit format ?

We can see here that MS-DOS dates look like this:

0000001000100001
           ^~~~~
           day of month
       ^~~~
       month
^~~~~~~
year offset from 1980

and MS-DOS times look like this:

0000100000100001
           ^~~~~
           second / 2
     ^~~~~~
     minute
^~~~~
hour

Interesting! MS-DOS time has resolution of 2 seconds.

That explains the strange 1:01:02 time from the beginning. January 1, 1981 1:01:02 is the date time you get when all fields in MS-DOS date time are filled in with 1s.

Updated: