Sorry my phrasing was bad and made it confusing. Let me explain it in detail.
They correctly choose a unsigned int for the time but they based it on Unix time, and Unix time is signed. So they choose a system that would require an conversion from Unix time to Bitcoin time (or the other way around) anyway. But you don’t need to be able to have a timestamp for 1970, which their timestamp system supports, because instead of counting from 2008 (the invention of Bitcoin) they count from 1970. Wasting 38 years and as you know Unix time is hitting a limit in 2038, 68 years after its start, Bitcoin time is unsigned and so it gets to 2106. 2106-1970= 136 years. And they are wasting 38 years!!! Why? You need a conversion between both after 2038 anyway. And if they really care for cheap conversion, a signed 64bit value would be much better, because after 2038, that will probably be the standard. So they chose to waste 38 years for compatibility which will break after 2038, instead of choosing compatibility after 2038 for 292 billion years.
And if size was the reason and 64bit timestamps would have been too big, just start counting from 2008 (or better 2009 when the network started) and get all those juicy 136 years instead of 98 years.
or they can simply inherit the UNIXTIME library, in which 0 has shifted from 1970 to 2038, and add one additional “time epoch” flag. Think about what’s easier - create your own time library or inherit from unixtime?
Sorry my phrasing was bad and made it confusing. Let me explain it in detail.
They correctly choose a unsigned int for the time but they based it on Unix time, and Unix time is signed. So they choose a system that would require an conversion from Unix time to Bitcoin time (or the other way around) anyway. But you don’t need to be able to have a timestamp for 1970, which their timestamp system supports, because instead of counting from 2008 (the invention of Bitcoin) they count from 1970. Wasting 38 years and as you know Unix time is hitting a limit in 2038, 68 years after its start, Bitcoin time is unsigned and so it gets to 2106. 2106-1970= 136 years. And they are wasting 38 years!!! Why? You need a conversion between both after 2038 anyway. And if they really care for cheap conversion, a signed 64bit value would be much better, because after 2038, that will probably be the standard. So they chose to waste 38 years for compatibility which will break after 2038, instead of choosing compatibility after 2038 for 292 billion years.
And if size was the reason and 64bit timestamps would have been too big, just start counting from 2008 (or better 2009 when the network started) and get all those juicy 136 years instead of 98 years.
It is stupid.
or they can simply inherit the UNIXTIME library, in which 0 has shifted from 1970 to 2038, and add one additional “time epoch” flag. Think about what’s easier - create your own time library or inherit from unixtime?