Networked leap second handling and shared memory
Leap seconds are announced about 6 months in advance by the IERS in their Bulletin C. This means Sortix can't future UTC dates accurately in the future. It also means Sortix process has a lifetime of 6 months, or it might calculating the wrong dates as the leap second table is statically linked in libc. It also requires a Sortix that is recent enough to have the latest leap second, but Sortix releases aren't regular and often enough that this is feasible.
A proper solution would be for the kernel to store the leap second table in shared memory and each process has a copy of it made available. The leap second table can then be updated at runtime by a background daemon, allowing Sortix processes to eventually get the latest data so they can continue to calculate current dates and dates in the near future accurately. There should be a daemon that gets the leap second data from somewhere. The leap second table should probably be stored in /boot so the kernel has it available immediately during early boot. A single page bitmap, with 2 bits per month (no leap second, positive leap second, negative leap second, unknown) can store 170 years worth of leap seconds (there should be support for this being considerably larger so Sortix is very future proof, or we can guess it'll be abolished before then).