@mathew @alcinnz @radikalgrafitio yes, but no. Sure, because of leap seconds each year has a variable length. It _will_ be a problem if we need a second to second accurate timestamps, but, actually, for the abovementioned purposes we don't. In that case usage of Epoch timestamps will be less errorneus.
Need to store a table of leap second adjustments seems reasonable, because machine-to-human time conversions are relatively rare.
@peexea @alcinnz @radikalgrafitio
POSIX doesn't require leap second table support. You could implement your own epoch timestamp library separately from POSIX, I guess, but doing so in a way which will work with future timestamps is still going to be a nuisance, and you'll have to be careful that you don't use the standard calls anywhere. Or you could do what GPS does, and use a UT1 basis for your timestamps and have them drift away from UTC.
Or, you know, you could just use ISO-8601 ASCII.
You can't just change a variable to store things in a different format, because that will change the layout of the reports. So they were stuck with 2 digits for the year unless they wanted to change the output, and that would have taken a lot more work.
We can make a favor for futere programmers and redefine Epoch timestamps to the original "number of seconds from the 00:00:00 UTC of 01.01.1970". Such timestamps will be absolutely independent of the calendar changes but will make a translation to human-readable format harder.
IMHO, it is perfectly ok for enterprise and embedded systems.
For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).