Many 64bit systems with glibc uses a 32bit time_t for utmp, wtmp and lastlog, to provide compatibility with a 32bit userland.
As result, none of this files and corresponding functions/interfaces is Y2038 ready, not even on a pure 64bit architecture.
More information can be found on my Y2038 document.

The glibc developers refuse to fix this, as there are several more problems with utmp and they want to declare the utmp/wtmp/lastlog interfaces as deprecated and remove them in the future.
util-linux is one of the packages which are affected by this in a major way.

For every file we think currently about a different solution:

• Modify the few tools who read utmp and let them use systemd-logind instead, which has the same information. Long term we could stop writing utmp, until then, it's used for compatibility reasons.
• wtmp will be most likely replaced with structured data logged via journald
• btmp -> maybe we can use the wtmp interface as replacement? Or is this really from benefit? Not all login applications do support this and write an entry, so the data is incomplete
• lastlog seems only used by terminal applications (login, ssh), but not on Desktop systems. So I haven't found any Desktop system where lastlog provides correct data.

For replacing utmp with systemd-logind, libsystemd got three additional functions to access the missing information. systemd v254 should have them, they are already accepted in git. util-linux has agetty, lslogins, wall and write which would need to query logind and not read utmp, as far as I can see. For agetty and wall I mode a PoC: https://github.com/thkukuk/util-linux/tree/logind
Only the configure option to enable it is missing.
lslogins is doable, but more work and I wanted to get at first some feedback before starting with this.
For write and wall it's the question if this tools still make sense today? For desktops, users either feel spammed by them or don't get the message at all (if they don't use a terminal application), here clearly a more modern solution is required.
Maybe we could just add an option to disable building of wall and write?

For lastlog I would also prefer if this could be disabled, or at least that the tools don't write lastlog entries if the file does not exist. Like shadow. If lastlog should be kept, we need a new file format and a migration plan.