FW: 32-bit 2038 issue
Tom Peterson (USG)
tomp at zk3.dec.com
Fri Nov 21 18:32:13 UTC 1997
> > > changing time_t to an unsigned int would give another 68 years
> > But that would break backward compatibility with many applications.
> > Few vendors have gone to an unsigned time_t (in fact, I don't know of
> > any offhand) and there are good reasons for this.
> A possibility would be to interpret the values in time zone files
> as unsigned WITHOUT changing the type of time_t.
Wouldn't this prevent access to all the historical time data before 1970? In
Paul's birthday example, we'd have no way of knowing what rules to apply when
attempting to represent his birth date. Also, wouldn't this still require
breaking compatibility with the existing file format? Applications or
libraries would still need to recompile.
While this approach might buy us another 68 years, it still only moves the bar
up a certain amount. There's bound to be situations where people need to
extrapolate dates into the future past whatever boundary we set. As long as
we're looking at changing the file format, I'd opt for storing algorithmic
data, perhaps using something like POSIX.1 strings as Paul suggested.
More information about the tz