I'll quote myself again, "Oh I agree its a bad long term solution, but assuming they had noticed and used the correct type, 2043 is likely well past the lifetime of the product and would have worked fine till then"
I never suggested it was any improvement except for the advantage of time; although I shouldn't have used the word 'correct'. Signed 32-bit dates have a well known limitation that people will likely hunt and fix over the next 20 years. But yes, its all unsubstantiated, no doubt there.
The real main point of my post you first replied to is that it doesn't matter that the version was stored as an integer. The failure happened when they used their own format and didn't confirm it was properly bounded. Everyone here is having a hard time grasping how their data is stored and processed at the low level - your 'string' is still just an array of 8-bit bytes.
Storing an only-increasing number as any form of integer is a perfectly acceptable, and efficient way for a computer to compare and process. Version numbers are one of those. Phone numbers are obviously not.
I never suggested it was any improvement except for the advantage of time; although I shouldn't have used the word 'correct'. Signed 32-bit dates have a well known limitation that people will likely hunt and fix over the next 20 years. But yes, its all unsubstantiated, no doubt there.
The real main point of my post you first replied to is that it doesn't matter that the version was stored as an integer. The failure happened when they used their own format and didn't confirm it was properly bounded. Everyone here is having a hard time grasping how their data is stored and processed at the low level - your 'string' is still just an array of 8-bit bytes.
Storing an only-increasing number as any form of integer is a perfectly acceptable, and efficient way for a computer to compare and process. Version numbers are one of those. Phone numbers are obviously not.