Well. Programming, like life in general, is made out of imperfections. There is a shitload of corner-cases in APIs both ancient and modern that you cannot poss

Well. Programming, like life in general, is made out of imperfections. There is a shitload of corner-cases in APIs both ancient and modern that you cannot possibly "fix for all" or, alternatively, learn to avoid. In many cases, it suffices to take that %G after a cursory glance, bump into some weird non-continuous dates later, read the man page again in the heat of a WTF, and change it to %F. There are applications and cases where dates, and especially the exactness, correctness, and coherency of dates, is of some hugely important factor. Software for banking, accounting, train scheduling, or flying come to mind. In these cases the standard library behaviour can be tested for expected values, or rather, a custom and audited library be written by the team. But for the majority of programs, things like little glitches in dates, compatibility of encoding conventions in file names and paths, floating point numbers used as decimals etc. will be of little significance. It takes a lot of these to align to unlock one big disaster, and while it is good to strive for perfection there's always a cost to all the little things. If the failures are manageable it is often more practical to just wait for those that will eventually happen.