Possibly at the time. Definitely, a mere 20 years in. I for one wrote a 32-bit C++ standard library in the early 1990s, and I used a 64-bit time_t. It ran on top of 32-bit OS/2, which was already keeping time internally using a 64-bit integer. I published two toolkits of command-line utilities, including a replacement DATE command, that used it.
I wasn't alone in this, by any means. Other library writers were implementing this.
Solaris went 64-bit in the 1990s, as did IRIX. Windows NT had a 64-bit (albeit different) time format from the 32-bit start. TAI64NA was invented in 1997.
AIX was late to the game for sure, but I don't think it was quite that late.
It was more like AIX 4.3, that added the ability to run 64-bit code on a 32-bit OS. As part of that effort all the syscalls were double defined, one for older 32-bit only applications and another for 64-bit applications running on the 32-bit OS. By AIX 5, there was a native 64-bit kernel as well. Pretty sure that between those events the header files were tweaked so all newly built applications were using the 64-bit time_t calls unless a compatibility flag was defined.
It was 5.3 that gained the 64-bit time API. Prior to that, there was only 32-bit time_t, even on 64-bit AIX. See Redbook SG247463 section 5.19 ("Date APIs past 2038").
* http://jdebp.uk./FGA/keeping-time-in-os2.html
I wasn't alone in this, by any means. Other library writers were implementing this. Solaris went 64-bit in the 1990s, as did IRIX. Windows NT had a 64-bit (albeit different) time format from the 32-bit start. TAI64NA was invented in 1997.
* https://cr.yp.to/libtai/tai64.html
Thinking about this in the 2010s and 2020s is somewhat late. Indeed, even AIX 5.3 in 2004 was comparatively late.