SOA SERIAL is unsigned 32-bit number. Thus anything you wrote about the internal time representation just doesn’t apply, neither signed 32-bit nor 64-bit time_t has any effect on SOA serial integer type.
Ondřej -- Ondřej Surý (He/Him) [email protected] ADHD brain at work: I sometimes lose track of my inbox. Please feel free to send a gentle nudge if you're waiting on a reply! My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 21. 7. 2026, at 20:47, Paul Kosinski <[email protected]> wrote: > > 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.
