| Forum messages are synchronized
with Usenet.
|
|
|
| Author |
Message |
robert w hall
Guest
|
 Posted: Wed Dec 03, 2003 5:49 am Post subject: time to put that 2038 bug in the forward plan |
 |
|
I was looking through the forward programme of a large UK engineering
firm today, whose 'products' typically last for 40 to 50 years.
They have a committment to resolve by 31st December 2020 the
implications of the fast-approaching and infamous UNIX date bug, due
real soon now, in 2038.
Now that's what I call good forward planning...
Bob
--
robert w hall |
|
| Back to top |
|
 |
|
|
Bit Twister
Guest
|
| Posted: Wed Dec 03, 2003 7:06 am Post subject: Re: time to put that 2038 bug in the forward plan |
|
|
On Tue, 2 Dec 2003 23:49:43 +0000, robert w hall wrote:
| Quote: | I was looking through the forward programme of a large UK engineering
firm today, whose 'products' typically last for 40 to 50 years.
They have a committment to resolve by 31st December 2020 the
implications of the fast-approaching and infamous UNIX date bug, due
real soon now, in 2038.
Now that's what I call good forward planning...
|
They have to. Companies are going to need a year to hunt down the
source code, apply the changes, write the test plans, install running
code on a testbed, write install/patch procedures, do the testshot
and fix all code, patches, documents, clear the testbed, and do the
second test shot. This assumes the test teams have no other duties
like all the stuff they already do daily. Geeze I was there.
Now that brings the deadline back to 2037 for the end users to get the
OS fixes. The OS vendor have to do all the above for all the releases
that they support for all the versions of the compilers they
support. That will need a 3 to 5 year lead. So let's say that takes us
back to 2030.
Now 2030-2004 gives us 26 years which seems like a lot.
But, you can bet the next 10 years will continue with the outsourcing
of programming to offshore companies. That will be enough time to
kill the programming classes at universities for the onshore countries.
So there we are with 16 years for the offshore talent to fix, test,
document all the code running in the world.
Remember I started with 2004 not 2020 which gives us 2020-2004=16.
IF any managers decide they better get their code fixed 15 years
early. Yeah right.
Hmmm, make note to self to buy stock in programming companies and sell
in 2035. Gives me 3 years to buy farm and learn to grow/store food. |
|
| Back to top |
|
|
mjt
Guest
|
| Posted: Wed Dec 03, 2003 7:12 am Post subject: Re: time to put that 2038 bug in the forward plan |
|
|
On Tue, 2 Dec 2003 23:49:43 +0000, robert w hall <bobh@n-cantrell.demon.co.uk> wrote:
| Quote: | infamous UNIX date bug,
|
.... it's history
..
--
/// Michael J. Tobler: motorcyclist, surfer, skydiver, \\\
\\\ and author: "Inside Linux", "C++ HowTo", "C++ Unleashed" ///
"If you've done six impossible things before breakfast, why not round
it off with dinner at Milliway's, the restaurant at the end
of the universe?" |
|
| Back to top |
|
|
Sybren Stüvel
Guest
|
| Posted: Wed Dec 03, 2003 8:36 am Post subject: Re: time to put that 2038 bug in the forward plan |
|
|
On Tue, 02 Dec 2003 23:49:43 +0000, robert w hall wrote:
| Quote: | They have a committment to resolve by 31st December 2020 the
implications of the fast-approaching and infamous UNIX date bug, due
real soon now, in 2038.
|
I'm already running into problems due to the 2038 limit. I'm working on a
system that can calculate pensions (you know, the money you get when you
quit your job on your 65th) and people that use the system now will be 65
after 2038 and we have to make calculations for years 2039+.
Sybren
--
(o_ Q: God, root, what is difference?
//\ A: God can change the byte order on the CPU, root can't.
V_/_ |
|
| Back to top |
|
|
mjt
Guest
|
| Posted: Wed Dec 03, 2003 10:11 am Post subject: Re: time to put that 2038 bug in the forward plan |
|
|
On Wed, 03 Dec 2003 03:36:59 +0100, Sybren Stüvel <sybrenUSE@YOURimagination.thirdtower.com> wrote:
| Quote: | I'm already running into problems due to the 2038 limit. I'm working on a
system that can calculate pensions (you know, the money you get when you
quit your job on your 65th) and people that use the system now will be 65
after 2038 and we have to make calculations for years 2039+.
|
.... come on now!!! there are money and specialized math
libraries out there to handle all this
..
--
/// Michael J. Tobler: motorcyclist, surfer, skydiver, \\\
\\\ and author: "Inside Linux", "C++ HowTo", "C++ Unleashed" ///
Sex is like a bridge game - If you have a good hand
no partner is needed. |
|
| Back to top |
|
|
John Hasler
Guest
|
| Posted: Wed Dec 03, 2003 10:38 am Post subject: Re: time to put that 2038 bug in the forward plan |
|
|
Sybren Stüvel writes:
| Quote: | I'm already running into problems due to the 2038 limit. I'm working on a
system that can calculate pensions (you know, the money you get when you
quit your job on your 65th) and people that use the system now will be 65
after 2038 and we have to make calculations for years 2039+.
|
Even if you really need to use epoch time in your program you can store it
in a long int.
--
John Hasler
john@dhh.gt.org
Dancing Horse Hill
Elmwood, Wisconsin |
|
| Back to top |
|
|
Sybren Stüvel
Guest
|
| Posted: Wed Dec 03, 2003 3:31 pm Post subject: Re: time to put that 2038 bug in the forward plan |
|
|
On Wed, 03 Dec 2003 04:11:32 +0000, mjt wrote:
| Quote: | ... come on now!!! there are money and specialized math
libraries out there to handle all this
|
Eh, but when you don't get paid and have to do things rapidly because it
had to be finished half a year ago (but things were more difficult than
expected) there is very little time and especially very little money to
fix that... But it's nice to know there is such a thing :)
Sybren
--
(o_ Q: God, root, what is difference?
//\ A: God can change the byte order on the CPU, root can't.
V_/_ |
|
| Back to top |
|
|
Sybren Stüvel
Guest
|
| Posted: Wed Dec 03, 2003 8:17 pm Post subject: Re: time to put that 2038 bug in the forward plan |
|
|
On Tue, 02 Dec 2003 22:38:25 -0600, John Hasler wrote:
| Quote: | Even if you really need to use epoch time in your program you can store it
in a long int.
|
I know there are workarounds - and we used them too. I was just merely
making a statement that waiting until 2020 to fix the 2038 bug might be a
little late... Why not fix it now if we have the knowledge?
Sybren
--
(o_ Q: God, root, what is difference?
//\ A: God can change the byte order on the CPU, root can't.
V_/_ |
|
| Back to top |
|
|
J.O. Aho
Guest
|
| Posted: Wed Dec 03, 2003 9:14 pm Post subject: Re: time to put that 2038 bug in the forward plan |
|
|
Sybren Stüvel wrote:
| Quote: | On Tue, 02 Dec 2003 22:38:25 -0600, John Hasler wrote:
Even if you really need to use epoch time in your program you can store it
in a long int.
I know there are workarounds - and we used them too. I was just merely
making a statement that waiting until 2020 to fix the 2038 bug might be a
little late... Why not fix it now if we have the knowledge?
|
So you mean it's not like start working on a millenium bug in a nonamed "os"
untill 1999 and think it will be finished before 2000?
The 'bug' is known, there is plenty of time, those who don't fix it, have to
accept that their dates do not match. Customers of close source products
should ask the developer of the software if they have fixed their software, if
the company still is around.
//Aho |
|
| Back to top |
|
|
Ivan Marsh
Guest
|
| Posted: Wed Dec 03, 2003 9:43 pm Post subject: Re: time to put that 2038 bug in the forward plan |
|
|
On Tue, 02 Dec 2003 23:49:43 +0000, robert w hall wrote:
| Quote: | I was looking through the forward programme of a large UK engineering
firm today, whose 'products' typically last for 40 to 50 years.
They have a committment to resolve by 31st December 2020 the
implications of the fast-approaching and infamous UNIX date bug, due
real soon now, in 2038.
Now that's what I call good forward planning... Bob
|
Actual conversation I had with my boss:
ME: Yes boss, our systems are all Y2k compliant. We don't run into a date
issue until 2038.
BOSS: Well, what do we do then?
ME: I'll be dead.
BOSS: (Very disturbed look on his face as he realizes he will be dead
too).
--
i.m.
The USA Patriot Act is the most unpatriotic act in American history. |
|
| Back to top |
|
|
Guest
|
| Posted: Thu Dec 04, 2003 12:03 am Post subject: Re: time to put that 2038 bug in the forward plan |
|
|
On Tue, 2 Dec 2003 23:49:43 +0000, robert w hall
<bobh@n-cantrell.demon.co.uk> wrote:
| Quote: | I was looking through the forward programme of a large UK engineering
firm today, whose 'products' typically last for 40 to 50 years.
They have a committment to resolve by 31st December 2020 the
implications of the fast-approaching and infamous UNIX date bug, due
real soon now, in 2038.
Now that's what I call good forward planning...
Bob
|
This *bug* (as you put it) is based on 32 bit machines. So there is
no bug. We have already have 64 bit machines from AMD and Intel. In
a few years 32 bit machines will be available only on ebay right next
to the commodore 64s.
The 2038 BUG is no bug.
Just like the y2k problem was no Millennium bug. It wasn't a bug and
it wasn't the millenium.
Snide |
|
| Back to top |
|
|
Ivan Marsh
Guest
|
| Posted: Thu Dec 04, 2003 12:25 am Post subject: Re: time to put that 2038 bug in the forward plan |
|
|
On Wed, 03 Dec 2003 18:03:33 +0000, snid wrote:
| Quote: | On Tue, 2 Dec 2003 23:49:43 +0000, robert w hall
bobh@n-cantrell.demon.co.uk> wrote:
I was looking through the forward programme of a large UK engineering
firm today, whose 'products' typically last for 40 to 50 years.
They have a committment to resolve by 31st December 2020 the
implications of the fast-approaching and infamous UNIX date bug, due
real soon now, in 2038.
Now that's what I call good forward planning... Bob
This *bug* (as you put it) is based on 32 bit machines. So there is no
bug. We have already have 64 bit machines from AMD and Intel. In a few
years 32 bit machines will be available only on ebay right next to the
commodore 64s.
The 2038 BUG is no bug.
Just like the y2k problem was no Millennium bug. It wasn't a bug and it
wasn't the millenium.
Snide
|
I think most people are aware of that... people that know about it anyway.
It's just too much of a pain to say "design limitataion".
Although I did think it was very telling about the public in general that
the "Millennium bug" wasn't a bug and didn't happen on the millennium.
--
i.m.
The USA Patriot Act is the most unpatriotic act in American history. |
|
| Back to top |
|
|
Lew Pitcher
Guest
|
| Posted: Thu Dec 04, 2003 12:39 am Post subject: Re: time to put that 2038 bug in the forward plan |
|
|
snide@milleniumbug.com wrote:
| Quote: | On Tue, 2 Dec 2003 23:49:43 +0000, robert w hall
bobh@n-cantrell.demon.co.uk> wrote:
I was looking through the forward programme of a large UK engineering
firm today, whose 'products' typically last for 40 to 50 years.
They have a committment to resolve by 31st December 2020 the
implications of the fast-approaching and infamous UNIX date bug, due
real soon now, in 2038.
Now that's what I call good forward planning...
Bob
This *bug* (as you put it) is based on 32 bit machines.
|
More specifically, this /bug/ is the result of defining time_t as a 32bit
signed integer. Any OS implementation that defines time_t as something
greater than 32bits will suffice; current 32bit operating systems can use a
long int and avoid the 2038 bug entirely.
Speaking of which...
pitchl@srdscs05:~$ uname -a
Linux srdscs05 2.4.21 #6 Mon Jun 16 17:12:59 PDT 2003 i586 unknown
pitchl@srdscs05:~$ man 2 time
TIME(2) Linux Programmer's Manual TIME(2)
NAME
time - get time in seconds
SYNOPSIS
#include <time.h>
time_t time(time_t *t);
DESCRIPTION
time returns the time since the Epoch (00:00:00 UTC, Jan-
uary 1, 1970), measured in seconds.
pitchl@srdscs05:~$ grep time_t /usr/include/time.h
...
typedef __time_t time_t;
pitchl@srdscs05:~$ grep include /usr/include/time.h
# include <features.h>
# include <stddef.h>
# include <bits/time.h>
pitchl@srdscs05:~$ grep time_t /usr/include/bits/types.h
typedef long int __time_t;
It looks like the Intel x86 version of the Linux 2.4.21 kernel (courtesy of
Slackware Linux 9.0) /already/ defines time_t as a long int, and thus has
avoided and fixed the 2038-problem in 2003.
| Quote: | So there is
no bug. We have already have 64 bit machines from AMD and Intel. In
a few years 32 bit machines will be available only on ebay right next
to the commodore 64s.
|
See above. Fix is already in place, and doesn't need replacement of hardware.
--
Lew Pitcher, IT Consultant, Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group
(Opinions expressed here are my own, not my employer's) |
|
| Back to top |
|
|
robert w hall
Guest
|
| Posted: Thu Dec 04, 2003 12:48 am Post subject: Re: time to put that 2038 bug in the forward plan |
|
|
In article <iv8ssvsln403jrlr9qpdipg8tg9l90pqo2@4ax.com>,
snide@milleniumbug.com writes
| Quote: | This *bug* (as you put it) is based on 32 bit machines. So there is
no bug. We have already have 64 bit machines from AMD and Intel. In
a few years 32 bit machines will be available only on ebay right next
to the commodore 64s.
The 2038 BUG is no bug.
Just like the y2k problem was no Millennium bug. It wasn't a bug and
it wasn't the millenium.
Snide
|
ahem - embedded systems ???
you can't just whip out the control systems every 3 years like MS says
(and Concorde for example flew for 25 years)
--
robert w hall |
|
| Back to top |
|
|
Lew Pitcher
Guest
|
| Posted: Thu Dec 04, 2003 12:49 am Post subject: Re: time to put that 2038 bug in the forward plan |
|
|
Lew Pitcher wrote:
[snip]
| Quote: | It looks like the Intel x86 version of the Linux 2.4.21 kernel (courtesy
of Slackware Linux 9.0) /already/ defines time_t as a long int, and thus
has avoided and fixed the 2038-problem in 2003.
|
Oops. I should have checked - long int is still 32bits. So, let's get GCC
changed for a longer long int (48 bits or more) and everything will work out.
--
Lew Pitcher, IT Consultant, Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group
(Opinions expressed here are my own, not my employer's) |
|
| Back to top |
|
|
|
|
|
|
Search
Register
Log in to check your private messages
Profile
Log in
FAQ
Memberlist
Usergroups