Re: Polite enquiry as to if anyone is working on 64 bit time_t, and if so, what's the plan?
On 21/10/2011 12:33 AM, Henning Brauer wrote: > * Janne Johansson [2011-10-20 15:11]: >> 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. > > anything clean just uses time_t and is thus fixed by recompiling. > > now, reality check, there is way too much crap out there that makes > dumb assumptions. but "many of them use 32 bits today" makes it sound > like a) that was common and b) right. it isn't. certainly not b). time > will tell us (oh the irony) about a). > I was hoping to hear if there was a plan or if someone was working on moving to 64 bit time_t, I have been digging around in the source code of -current recompiling the kernel with arch amd64 _types.h time_t typedef'd as __int64_t but am now tracing where else it is defined and other compilation errors, is what I am trying to do madness and there is a known thing that won't be changed? That is to say, am I wasting my time (ha)?
Re: Polite enquiry as to if anyone is working on 64 bit time_t, and if so, what's the plan?
On Thu, Oct 20, 2011 at 9:44 AM, Nick Bender wrote: > NTP (from wikipedia): > >Implementations should disambiguate NTP time using a knowledge >of the approximate time from other sources. Since NTP only works >with the differences between timestamps and never their absolute >values, the wraparound is invisible as long as the timestamps are >within 68 years of each other. So, we just need to worry about upgrading an OpenBSD 1.0 box to OpenBSD 15, and have ntp screw up, 50 years from now? I have to wonder if OpenBSD 15 will still run on 386, Alpha and m68k -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk "This officer's men seem to follow him merely out of idle curiosity." -- Sandhurst officer cadet evaluation. "Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted." -- Gene Spafford learn french: http://www.youtube.com/watch?v=30v_g83VHK4
Re: Polite enquiry as to if anyone is working on 64 bit time_t, and if so, what's the plan?
On Thu, Oct 20, 2011 at 7:33 AM, Henning Brauer wrote: > * Janne Johansson [2011-10-20 15:11]: >> 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. > > anything clean just uses time_t and is thus fixed by recompiling. > > now, reality check, there is way too much crap out there that makes > dumb assumptions. but "many of them use 32 bits today" makes it sound > like a) that was common and b) right. it isn't. certainly not b). time > will tell us (oh the irony) about a). Not a) for the two examples mentioned. HTTP Expires header: ascii date string. Good until at least ... NTP (from wikipedia): Implementations should disambiguate NTP time using a knowledge of the approximate time from other sources. Since NTP only works with the differences between timestamps and never their absolute values, the wraparound is invisible as long as the timestamps are within 68 years of each other. -N
Re: Polite enquiry as to if anyone is working on 64 bit time_t, and if so, what's the plan?
* Janne Johansson [2011-10-20 15:11]: > 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. anything clean just uses time_t and is thus fixed by recompiling. now, reality check, there is way too much crap out there that makes dumb assumptions. but "many of them use 32 bits today" makes it sound like a) that was common and b) right. it isn't. certainly not b). time will tell us (oh the irony) about a). -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: Polite enquiry as to if anyone is working on 64 bit time_t, and if so, what's the plan?
2011/10/19 Michael T. Davis > >> 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
Re: Polite enquiry as to if anyone is working on 64 bit time_t, and if so, what's the plan?
At 09:05:01.75 on 19-OCT-2011 in message , Janne Johansson wrote: >2011/10/19 Bruce Drake > >> 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.) > >-- > To our sweethearts and wives. May they never meet. -- 19th century toast > Regards, Mike
Re: Polite enquiry as to if anyone is working on 64 bit time_t, and if so, what's the plan?
2011/10/19 Bruce Drake > 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. -- To our sweethearts and wives. May they never meet. -- 19th century toast
Polite enquiry as to if anyone is working on 64 bit time_t, and if so, what's the plan?
Hi 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. Regards, Bruce
