stdcerr
Reputation: 15658
stay compatible past 2038
I'm writing a piece of code that I want to work even past 2038. I need to store an epoch timestamp in a map and was wondering if I am compatible going forward when I use a long long instead of an int to store tiume(NULL) or how else I best go about this? I'm aware that even using an unsigned int would give nme plenty of more room - but is that or long long the best way to go about it?
Upvotes: 0
Views: 131
Answers (0)
Related Questions
- What should we do to prepare for 2038?
- how to apply leap year check logic in cobol
- 2-digit year to 4 digit specifier in strptime
- Can't use year more than "2038" in date field : Java
- boost timed_wait doesn't wait if date is in 2116 year
- calendar time stored as a signed 32-bit integer - when will it overflow
- How to get year from POSIX date
- Only accept two or four digit years from users
- Why should a Java programmer care about year 2038 bug?
- incorrect epoch unix time value for larger year (2048)