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