Bug 4853 - sys_timeBase should change to time_t to properly allow 2038+
Status: RESOLVED FIXED
Alias: None
Product: ioquake3
Classification: Unclassified
Component: Platform
Version: unspecified
Hardware: All other
: P3 normal
Assignee: Zachary J. Slater
QA Contact: ioquake3 bugzilla mailing list
URL:
Depends on:
Blocks:
 
Reported: 2010-12-19 08:13 EST by tinkah
Modified: 2010-12-19 19:43:19 EST
1 user (show)

See Also:


Description tinkah 2010-12-19 08:13:53 EST 
According to http://stackoverflow.com/questions/4482703/is-there-a-benefit-in-using-unsigned-long-for-timeval-members/4482969#4482969

Apparently, it's currently on unsigned long but it appears to properly go 2038+ it needs time_t since then system should properly deal with it anyway.
Comment 1 tinkah 2010-12-19 08:15:50 EST 
Also, partially relevant, the comments it has in there appear outdated. e.g. Sys_XTimeToSysTime() doesn't exist anymore (due to SDL change?).
Comment 2 Tim Angus 2010-12-19 12:46:48 EST 
While this is technically correct, the risk to disrupting existing code is far greater than the actual proble herem. If anyone is still using Q3 in 27 years or unsigned long isn't bigger by then, something is horribly wrong.

Fixed the comment though.
Comment 3 tinkah 2010-12-19 19:43:19 EST 
unsigned long goes beyond 2038. The point was that that any OS designed to work beyond 2038 (e.g anything that could be sold around 2020 onwards) would have a time_t that works for it since it's ..'time'_t.

some programmers worry that time_t will remain 32bit to support backwards compatibility but it's silly believing OSes will let everything break at 2038 to support legacy code up to the last moment of 2037.

PS. Some believe 'long' will be 64bit everywhere in some time but in that logic time_t is better since it is for time after all (and what timeval supports).