On Wed, Dec 22, 1999 at 01:55:17PM -0900, Aaron Dewell wrote:
Or February 6, 2106 at 6:28:14 if your UNIX system keeps an unsigned 32-bit time_t. I Y2.038k tested my Solaris 7 box, it kept time past 3:14 AM 1/19/38, but the date command would not set it. Which implies that the kernel itself is unsigned, while the date command uses a signed number.
Wasting an entire 2 billion seconds to check for a -1 error condition instead of the one's complement 0xFFFFFFFF is remarkably stupid imho. But it would break a lot of userland programs to change. As far as I know in BSD it is still a signed long, at least in machine/ansi.h. -- Richard A. Steenbergen <ras@above.net> http://users.quadrunner.com/humble PGP Key ID: 0x60AB0AD1 (E5 35 10 1D DE 7D 8C A7 09 1C 80 8B AF B9 77 BB) AboveNet Communications - AboveSecure Network Security Engineer, Vienna VA "A mind is like a parachute, it works best when open." -- Unknown
Or February 6, 2106 at 6:28:14 if your UNIX system keeps an unsigned 32-bit time_t. I Y2.038k tested my Solaris 7 box, it kept time past 3:14 AM 1/19/38, but the date command would not set it. Which implies that the kernel itself is unsigned, while the date command uses a signed number.
Wasting an entire 2 billion seconds to check for a -1 error condition instead of the one's complement 0xFFFFFFFF is remarkably stupid imho. But it would break a lot of userland programs to change. As far as I know in BSD it is still a signed long, at least in machine/ansi.h.
it's not signed just so that you can check for a -1 error condition, it's signed so that you can say time "a" - time "b" gives number of seconds "c", where "c" may be positive or negative (ie, the difference between two points in time is easily presentable). you may never have used this particular functionality, but that's why it's there. it's easy to say "just make it unsigned and you will win another 68 years!", but you have to consider *all* of the uses of a time_t. the time in the (any) kernel is kept as signed so that it's in sync with the rest of unix stuff. you can call it unsigned, since it will (probably) never go back beyond 1970, but that's picking nits. as for the kernel keeping time beyond 2038, it's just incrementing a kernel variable. there's no check in any c code you write for integer overflow...it just goes negative. try setting your clock to just before the roll over, letting it roll over, and then touch a file and see what ls says. or date. date probably just doesn't like to parse things beyond that date. it would be better, imho, to go to a 64 bit signed time_t, but that would be a major flag day. -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth."
[ On Wednesday, December 22, 1999 at 23:58:21 (-0500), Andrew Brown wrote: ]
Subject: Re: Silly season
it would be better, imho, to go to a 64 bit signed time_t, but that would be a major flag day.
"would be"!?!?! :-) No, it *WILL* be an important day, but it will happen on a per-system basis (and perhaps per-protocol basis if indeed there are any network protocols carrying time_t or similar values). -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
Greg A. Woods Sent: Thursday, December 23, 1999 11:28 AM
[ On Wednesday, December 22, 1999 at 23:58:21 (-0500), Andrew Brown wrote: ]
Subject: Re: Silly season
it would be better, imho, to go to a 64 bit signed time_t, but that would be a major flag day.
"would be"!?!?! :-)
No, it *WILL* be an important day, but it will happen on a per-system basis (and perhaps per-protocol basis if indeed there are any network protocols carrying time_t or similar values).
Those of us implementing 64-bit OS (Alpha, Merced, etc) get this as part of the package. However, this does NOT correct databases that already have a 32-bit time_t (which shouldn't be the case, but is a good probability [lazy coders]). Ergo, even the fact that 90% of the computers will be 64-bit safe by 2038 won't save us. Stored data will have to be checked and the conversion will obsolete many backup tapes. What I am saying is that there is still a data-migration issue, just like Y2K. The problem is only transitive in protocols and running code, there is not much inertia there, but the real problem is data in long-term storage, where inertia is the name of the game.
Btw, an idea. Some of you are tsting their system as they will work in 2000 year. This means the installation of the future time, isn't it? Why don't just tesh y2.038k too (it's not big difference how many different frauded dates to test - one /1 January 2000/ or 2 (1 Jan and this, 2038 /which day it will be, exactly?/ date). And my suggestion is that y2038k will be a very serious problem for the Unix-based systems and some network protocols, not as Y2K problem are. On Thu, 23 Dec 1999, Roeland M.J. Meyer wrote:
Date: Thu, 23 Dec 1999 11:44:57 -0800 From: Roeland M.J. Meyer <rmeyer@mhsc.com> To: 'North America Network Operators Group' <nanog@merit.edu> Subject: RE: Silly season
Greg A. Woods Sent: Thursday, December 23, 1999 11:28 AM
[ On Wednesday, December 22, 1999 at 23:58:21 (-0500), Andrew Brown wrote: ]
Subject: Re: Silly season
it would be better, imho, to go to a 64 bit signed time_t, but that would be a major flag day.
"would be"!?!?! :-)
No, it *WILL* be an important day, but it will happen on a per-system basis (and perhaps per-protocol basis if indeed there are any network protocols carrying time_t or similar values).
Those of us implementing 64-bit OS (Alpha, Merced, etc) get this as part of the package. However, this does NOT correct databases that already have a 32-bit time_t (which shouldn't be the case, but is a good probability [lazy coders]). Ergo, even the fact that 90% of the computers will be 64-bit safe by 2038 won't save us. Stored data will have to be checked and the conversion will obsolete many backup tapes. What I am saying is that there is still a data-migration issue, just like Y2K. The problem is only transitive in protocols and running code, there is not much inertia there, but the real problem is data in long-term storage, where inertia is the name of the game.
Aleksei Roudnev, (+1 415) 585-3489 /San Francisco CA/
I don't know how big of a deal is being made about 2.038K on a corporate management level, but it would seem that the ensuing months would be just about a perfect time to address this issue. After all, many companies have teams for the date-field issue right now, and we've gotten pretty good in the past couple of years at analyzing this problem. It would only make sense to immediately move on to the 2038 work after Y2K settles down. Let's just not wait until 2035 to deal with it this time, huh? - Steve ----- Original Message ----- From: Alex P. Rudnev <alex@virgin.relcom.eu.net> To: Roeland M.J. Meyer <rmeyer@mhsc.com> Cc: 'North America Network Operators Group' <nanog@merit.edu> Sent: Thursday, December 23, 1999 3:01 PM Subject: RE: Silly season
Btw, an idea. Some of you are tsting their system as they will work in
2000
year. This means the installation of the future time, isn't it? Why don't just tesh y2.038k too (it's not big difference how many different frauded dates to test - one /1 January 2000/ or 2 (1 Jan and this, 2038 /which day it will be, exactly?/ date).
And my suggestion is that y2038k will be a very serious problem for the Unix-based systems and some network protocols, not as Y2K problem are.
On Thu, 23 Dec 1999, Roeland M.J. Meyer wrote:
Date: Thu, 23 Dec 1999 11:44:57 -0800 From: Roeland M.J. Meyer <rmeyer@mhsc.com> To: 'North America Network Operators Group' <nanog@merit.edu> Subject: RE: Silly season
Greg A. Woods Sent: Thursday, December 23, 1999 11:28 AM
[ On Wednesday, December 22, 1999 at 23:58:21 (-0500), Andrew Brown wrote: ]
Subject: Re: Silly season
it would be better, imho, to go to a 64 bit signed time_t, but that would be a major flag day.
"would be"!?!?! :-)
No, it *WILL* be an important day, but it will happen on a per-system basis (and perhaps per-protocol basis if indeed there are any network protocols carrying time_t or similar values).
Those of us implementing 64-bit OS (Alpha, Merced, etc) get this as part of the package. However, this does NOT correct databases that already have a 32-bit time_t (which shouldn't be the case, but is a good probability [lazy coders]). Ergo, even the fact that 90% of the computers will be 64-bit safe by 2038 won't save us. Stored data will have to be checked and the conversion will obsolete many backup tapes. What I am saying is that there is still a data-migration issue, just like Y2K. The problem is only transitive in protocols and running code, there is not much inertia there, but the real problem is data in long-term storage, where inertia is the name of the game.
Aleksei Roudnev, (+1 415) 585-3489 /San Francisco CA/
Y2K: We'll know in 9 days. We'll suffer for a bit afterward. 32bitbug: I think we'd best leave this one alone until somewhere around 2020. By then I don't think most current system kernels will be in use, and, well, I'll be retired. Happy New Year to you all, Ehud Gavron ACES Research/RMI.NET Tucson
I don't know how big of a deal is being made about 2.038K on a corporate management level, but it would seem that the ensuing months would be just about a perfect time to address this issue. After all, many companies have teams for the date-field issue right now, and we've gotten pretty good in the past couple of years at analyzing this problem. It would only make sense to immediately move on to the 2038 work after Y2K settles down. Let's just not wait until 2035 to deal with it this time, huh?
- Steve
----- Original Message ----- From: Alex P. Rudnev <alex@virgin.relcom.eu.net> To: Roeland M.J. Meyer <rmeyer@mhsc.com> Cc: 'North America Network Operators Group' <nanog@merit.edu> Sent: Thursday, December 23, 1999 3:01 PM Subject: RE: Silly season
Btw, an idea. Some of you are tsting their system as they will work in
2000
year. This means the installation of the future time, isn't it? Why don't just tesh y2.038k too (it's not big difference how many different frauded dates to test - one /1 January 2000/ or 2 (1 Jan and this, 2038 /which day it will be, exactly?/ date).
And my suggestion is that y2038k will be a very serious problem for the Unix-based systems and some network protocols, not as Y2K problem are.
On Thu, 23 Dec 1999, Roeland M.J. Meyer wrote:
Date: Thu, 23 Dec 1999 11:44:57 -0800 From: Roeland M.J. Meyer <rmeyer@mhsc.com> To: 'North America Network Operators Group' <nanog@merit.edu> Subject: RE: Silly season
Greg A. Woods Sent: Thursday, December 23, 1999 11:28 AM
[ On Wednesday, December 22, 1999 at 23:58:21 (-0500), Andrew Brown wrote: ]
Subject: Re: Silly season
it would be better, imho, to go to a 64 bit signed time_t, but that would be a major flag day.
"would be"!?!?! :-)
No, it *WILL* be an important day, but it will happen on a per-system basis (and perhaps per-protocol basis if indeed there are any network protocols carrying time_t or similar values).
Those of us implementing 64-bit OS (Alpha, Merced, etc) get this as part of the package. However, this does NOT correct databases that already have a 32-bit time_t (which shouldn't be the case, but is a good probability [lazy coders]). Ergo, even the fact that 90% of the computers will be 64-bit safe by 2038 won't save us. Stored data will have to be checked and the conversion will obsolete many backup tapes. What I am saying is that there is still a data-migration issue, just like Y2K. The problem is only transitive in protocols and running code, there is not much inertia there, but the real problem is data in long-term storage, where inertia is the name of the game.
Aleksei Roudnev, (+1 415) 585-3489 /San Francisco CA/
Y2K: We'll know in 9 days. We'll suffer for a bit afterward.
yep. :)
32bitbug: I think we'd best leave this one alone until somewhere around 2020. By then I don't think most current system kernels will be in use, and, well, I'll be retired.
well...you could come out of retirement and fix all the systems, kinda like the cobol and fortran programmers in the sixties who thought no one would still be using their code any more after 30 years...look who was wrong? -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth."
On Thu, 23 Dec 1999, Steve Dispensa wrote:
I don't know how big of a deal is being made about 2.038K on a corporate management level, but it would seem that the ensuing months would be just about a perfect time to address this issue. After all, many companies have teams for the date-field issue right now, and we've gotten pretty good in the past couple of years at analyzing this problem. It would only make sense to immediately move on to the 2038 work after Y2K settles down. Let's just not wait until 2035 to deal with it this time, huh?
- Steve
Do you honestly believe that corporate *name your country* will spend the money NOW to fix a problem that won't affect them for 30+ years? One of us is living in a fantasy world.... -- Tim -------------------------------------------------- * Timothy M. Wolfe, Chief Network Engineer * * ClipperNet Corporation / It's a wireless world * * tim@clipper.net 800.338.2629 x 402 * * Sufficient for today = Inadequate for tomorrow * --------------------------------------------------
On Thu, Dec 23, 1999 at 02:37:13PM -0800, Tim Wolfe wrote:
On Thu, 23 Dec 1999, Steve Dispensa wrote:
I don't know how big of a deal is being made about 2.038K on a corporate management level, but it would seem that the ensuing months would be just about a perfect time to address this issue. After all, many companies have teams for the date-field issue right now, and we've gotten pretty good in the past couple of years at analyzing this problem. It would only make sense to immediately move on to the 2038 work after Y2K settles down. Let's just not wait until 2035 to deal with it this time, huh?
- Steve
Do you honestly believe that corporate *name your country* will spend the money NOW to fix a problem that won't affect them for 30+ years? One of us is living in a fantasy world....
Think about it this way. Would you rather the Y2K preperation "we must test our wall clocks for Y2K then fill out 20lbs of paperwork and affix a Y2K certified sticker" weenies found immediate employement, or would you rather see them go back to their go-pher my coffee jobs for the next 37 years? :P -- Richard A. Steenbergen <ras@above.net> http://users.quadrunner.com/humble PGP Key ID: 0x60AB0AD1 (E5 35 10 1D DE 7D 8C A7 09 1C 80 8B AF B9 77 BB) AboveNet Communications - AboveSecure Network Security Engineer, Vienna VA "A mind is like a parachute, it works best when open." -- Unknown
it would be better, imho, to go to a 64 bit signed time_t, but that would be a major flag day.
"would be"!?!?! :-)
okay...will be. when it happens. i wasn't trying to imply that it might not...i'm sure it will.
No, it *WILL* be an important day, but it will happen on a per-system basis (and perhaps per-protocol basis if indeed there are any network protocols carrying time_t or similar values).
um...like ntp? or the time protocol as per rfc868, a slightly adjusted (by 25567 days...gee has this expired already? :) time_t (well...okay, "a 32 bit binary number") protocol. fwiw - even if you're on a 64 bit system, any time_t you *expose* to the outside world is going to be converted to the 32 bit flavor. so you might be able to continue after 2038, but you'd probably be rather alone in it. and then there's tar, pax, cpio... -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth."
Cc: nanog@merit.edu Subject: Re: Silly season
On Wed, Dec 22, 1999 at 01:55:17PM -0900, Aaron Dewell wrote:
Or February 6, 2106 at 6:28:14 if your UNIX system keeps an unsigned 32-bit time_t. I Y2.038k tested my Solaris 7 box, it kept time past 3:14 AM 1/19/38,
Folks, time_t is _SIGNET LONG_, not unsigned one. And y2.038k is really a
problem, and can touch some real-time systems (Y2K can not, except some absolutelky crazy ones).
but the date command would not set it. Which implies that the kernel itself is unsigned, while the date command uses a signed number.
Wasting an entire 2 billion seconds to check for a -1 error condition instead of the one's complement 0xFFFFFFFF is remarkably stupid imho. But it would break a lot of userland programs to change. As far as I know in BSD it is still a signed long, at least in machine/ansi.h.
-- Richard A. Steenbergen <ras@above.net> http://users.quadrunner.com/humble PGP Key ID: 0x60AB0AD1 (E5 35 10 1D DE 7D 8C A7 09 1C 80 8B AF B9 77 BB) AboveNet Communications - AboveSecure Network Security Engineer, Vienna VA "A mind is like a parachute, it works best when open." -- Unknown
Aleksei Roudnev, (+1 415) 585-3489 /San Francisco CA/
participants (9)
-
Alex P. Rudnev -
Andrew Brown -
Deepak Jain -
Ehud Gavron -
Richard Steenbergen -
Roeland M.J. Meyer -
Steve Dispensa -
Tim Wolfe -
woods＠most.weird.com