On 3/21/20 2:06 PM, Hal Murray wrote:

...

As far as I can recall, only Android limits itself to 32-bit timestamps (expiring in 2039) among current operating systems, even the 32-bit OSes. I assume you mean time_t when you say "timestamps".

I should have been clearer. I was referring to the TZif files, not to time_t. That is, my understanding is that even 32-bit Debian, FreeBSD/Intel, etc. ship TZif files that support 64-bit timestamps. This is because zic.c (which these OSes use) generates only version-2 and version-3 TZif files, and these TZif files support 64-bit timestamps. Even when zic.c is compiled on a machine where time_t and long are only 32 bits wide, it should still generate 64-bit timestamps. In the old days these 64-bit TZif files were arguably overkill for 32-bit OSes, but even then the convenience of architecture-independence outweighed the disadvantage of bloat on 32-bit platforms. And now that Internet RFC 8536 says that version-1 TZif files should not be generated and that readers should ignore the version 1 header and data block in TZif files, only museum-piece platforms should have version-1 TZif files. By "museum-piece" I mean platforms derived from tzcode2006a and earlier, as 2006b introduced 64-bit support and no longer generated 32-bit-only TZif files. I hope we can safely ignore such platforms now.