|
|
|
|
|
|
by touchpadder
1182 days ago
|
|
|
Using negative values would only complicate things and the goal is to have a simple solution for not losing convenience of having a unix timestamp that fits in 32bits and is very straightforward. In 99.9% cases there will be no need to keep track of the epoch just like the current computers don't look before 1970. In rare cases if its required the epoch can obviously be stored in another byte. |
|
|
how so? as it happens computers handle this automatically when using a signed 32 bit integer. It's easy to implement because there is literally no extra work.
> In 99.9% cases there will be no need to keep track of the epoch just like the current computers don't look before 1970
so then why would you not suggest using unsigned 32 bits and going straight to 2106 that way?
I think you need to take some time and get comfortable with both 2s complement and modular arithmetic to understand the right trades for a solution to 2038 and why creating yet a new date standard of 2020 isn't a better idea than what's already been done and several other things that could have been. There are a lot of other gotchas and design decisions. That's why what I suggest is somewhat tongue in cheek and not a serious proposal. But it's objectively better in all criteria than starting again with 2020 (or 2000, or ...).
I leave you with: https://xkcd.com/927/