[MrIron-no]

Fixes #119.

Summary

Server-link timestamps were parsed with atoi(), which returns int and
therefore saturates at INT_MAX (2038-01-19 03:14:07 UTC) — the truncation
happens inside atoi(), before the value is widened into its time_t
destination, so it breaks even on a 64-bit time_t system.

The fix is input-only and protocol-neutral: ircd_snprintf's %Tu already
emits a full time_t, and timestamps travel as decimal ASCII, so a wide parse
is forward-compatible with existing peers and needs no protocol change.

Changes

New helper. time_t atotime(const char *) in ircd_string.c parses at full
width via strtoll().

~22 timestamp parses converted from atoi() to atotime():
server link start/timestamp (m_server), nick lastnick (m_nick,
s_user), channel creation TS (CREATE/JOIN/BURST/DESTRUCT), the MODE
recv_ts (channel.c), TOPIC times, INVITE, SETTIME, G-line
expire/lastmod/lifetime, jupe lastmod, and the RPING lag sample (its
local int widened to time_t).

Related 32-bit truncation. acc_id and acc_flags are uint64_t but were
parsed with atoi(); use strtoull() so account ids above 2^31 survive.

Left unchanged: non-time atoi() calls (ports, hop counts, protocol
numbers, op-levels, counts, umode masks, CAP version, millisecond RTT deltas).

Build guard (configure.ac). The fix assumes a 64-bit time_t. Added a
check that measures sizeof(time_t), tries the glibc remedy
(-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64) if it is smaller, and then warns by
default or fails under --enable-y2038-strict (for CI/release builds).
configure is generated and regenerated via autogen.sh, so only
configure.ac changes here.

Tests

Added an atotime() regression test to ircd_string_t asserting that a
post-2038 value (2200000000, 2039-09-13) round-trips intact on a 64-bit
time_t build, guarded so a legitimately 32-bit time_t build skips rather
than fails.

Validation

Built and run through the regular build (after ./autogen.sh):

• Full ircd binary builds clean, no new warnings.
• ircd_string_t passes; the post-2038 value is preserved (atoi would turn
  it into -2094967296).
• configure reports the 64-bit case silently; the warn and
  --enable-y2038-strict error paths were both exercised and fire correctly.

[MrIron-no]

Force-pushed an amend: the first pass missed three timestamp atoi() sites that issue #119 had listed — channel.c MODE recv_ts, s_user.c nick lastnick (both sites), and all of m_jupe.c (expire_off/lastmod). They are now converted to atotime(), and the commit message is corrected to match the actual diff. No timestamp atoi() remains; build and the atotime unit test are green.