2011/10/19 Michael T. Davis <dav...@ecr6.ohio-state.edu> > >> I found mention of a possible move to 64 bit time_t back in 2005 and 3.9 > >> was mentioned, but I see it hasn't happened. Is there a plan, like for > >> instance making all platforms, even 32 bit 64 bit time_t, like I think > >> NetBSD have tried/trying to do? > >> Can some one give a brief list of what needs to change, forgetting > about > >> ports, like UFS etc. that would be greatly appreciated. > >> > >> A lot of protocols? > >Its of no use if my machine knows it is Jan-1-2040 today if the HTTP > >cache-expires says "you may cache this until Jan-1-1904" or the ntpd > thinks > >UTC is at 1904 and I'm a "bit" off. > > You seem to be saying that applications need to be patched before > the underlying operating system (OS) can be considered. But isn't the OS > responsible for providing the "glue" (e.g. time-related include files and > libraries) with which applications are built? (This is coming from a > casual > user, so if I made the wrong inference from your statement, I'm happy to be > corrected.) > > What I meant was as you say, we can change the include file to say "use 64 bits for time" and recompile some apps, but if the database file format or the over-the-wire formats don't support 64 bits for specifying time, you'd be screwed anyway. That's why applications, formats and protocols need to change, since many of them use 32 bits today.
-- To our sweethearts and wives. May they never meet. -- 19th century toast
