On 1/3/2017 11:14 PM, Patrik Fältström wrote: > Well, if you look at the POSIX definition you see that it is clearly wrong the days when leap second is added: > > tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + > (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - > ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 > > > 2015-12-31 23:59:58 365th day 61409923198 > 2015-12-31 23:59:59 365th day 61409923199 > 2016-01-01 00:00:00 1st day 61409836800 > 2016-01-01 00:00:01 1st day 61409836801 > > 2016-12-31 23:59:59 366th day 61441459199 > 2016-12-31 23:59:60 366th day 61441459200 > 2017-01-01 00:00:00 1st day 61441459200 > 2017-01-01 00:00:01 1st day 61441459201 > > I.e. the real problem we have is a broken POSIX definition. It's as correct as it claims to be - it's an approximation. If anyone cares about a more precise back-calculation of Unix epoch from UTC, they would definitely need to consult a leap-second file. Joe