What is still affected?

64-bit desktops are mostly clear. Remaining cases are 32-bit images, 128-byte inodes, XFS without bigtime, and INT or TIMESTAMP columns.

Class	Status	Notes
64-bit desktop / server OS	Mostly clear	time_t is 64-bit. Application INT columns can still be 32-bit.
Modern iOS / 64-bit Android	Mostly clear	Old 32-bit Android 4-era devices are the exception.
32-bit Linux userland	Mixed	Kernel 5.6+ and glibc 2.34 can be time64. Debian i386 stays time32 on purpose.
ext4 large inodes	Extended	Extra epoch bits reach ~2446. 128-byte inodes do not.
XFS without bigtime	2038	Kernel logs “supports timestamps until 2038”. Enable or recreate with bigtime.
MySQL TIMESTAMP	2038	Use DATETIME or a 64-bit integer. UNIX_TIMESTAMP improved from 8.0.28 on 64-bit hosts.
Embedded / industrial / automotive	Case by case	Long life, rare updates, often 32-bit cores. Verify per product.
Windows FILETIME	Different clock	100 ns since 1601; not Unix time32. 32-bit CRT opt-in is the caveat.

A product is listed only with a vendor note, a kernel log, a schema limit, or a reproduced test.

A two-hour inventory, not a product list

Vendors rarely publish a time_t width. The checks are local:

On each Linux image, getconf LONG_BIT and bits/timesize.h. i386 Debian is time32 by policy. armhf after the Debian time64 rebuild is not.
On each volume, inode size or XFS bigtime. A 64-bit kernel mounts a 2038 filesystem without complaint until you read the mount warning.
On each database, TIMESTAMP and any INT whose name is a time. The server being 64-bit does not widen the column.
On each device that will still be installed in 2030, ask whether a firmware update exists. If the answer is no, the service life is the deadline. Put that date in the calculator.

Windows FILETIME is a different clock, 100 ns since 1601. It is not this bug. A 32-bit C runtime that still uses a 32-bit time_t on Windows is a separate, narrower caveat.