Sorry, I forgot that in original Unix (and many successors, such as Linux) the time counter is a *signed* 32-bit number. So (according to "https://en.wikipedia.org/wiki/Year_2038_problem";) the first problem appears at 03:14:07 UTC on 19 January 2038. Then, depending on the exact code behavior on overflow, the "time" goes negative, and becomes 20:45:52 UTC on 13 December 1901. It then counts forward from that, all the way up to 00:00:00 UTC on 1 January 1970. Maybe the 2106 date would apply if the 32-bit time counter were unsigned?
Since 2038 is only 12 years away, you probably will care. (I might not, since the first program I wrote was for the IBM 704 at Argonne National Lab.) In any case, many recent systems use a 64-bit seconds counter (clock), so they will not overflow for quite (!) a while. Also, the decimal representation of such a UnixTime presumably does not have a limit on the number of digits. Thus BIND could emit decimal Unix timestamps indefinitely, even beyond what a 4-digit year allows. --------------------------- On Tue, 21 Jul 2026 19:16:05 +0200 Ondřej Surý <[email protected]> wrote: > I don’t understand your question, but ai will try to answer it anyway. > > Personally, I don’t really care what happens in year 2106 as I am going to be > already dead anyway, but serial number follow the serial number arithmetics > which means the number will just roll to 0 and everything will continue to > work as 2^32-1 is less than 0. > > Ondřej > > > On 21. 7. 2026, at 19:00, Paul Kosinski <[email protected]> wrote: > > > > So BIND's UnixTime, being represented in decimal, allows values beyond > > 2^32-1 without any problem? -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.
