Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Unix and the year 2036 3

Status
Not open for further replies.
NuniPR

NuniPR

Programmer
Mar 3, 2005
55
PR
Hi Guys!!

I need some information regarding an error I've been hearing about Unix and the year 2036. According to everything I've been reading, there'll be a problem with the OS in year 2036, when the date/time on Jan 19 2036 will change to Dec 13 1901.

Does anyone know about this issue? What can we do to solve it or at least be prepared for it?

Thanks again for your help.



Nunina [gorgeous]
Cognos BI Administrator
San Juan, PR
 
Sort by date Sort by votes
We'll just have to start using a bigger data type to represent time. So... get a 64-bit computer sometime between now and 2036.
 
Upvote 0 Downvote
but not by me
Nor me, I guess (I'll be 81 ...)
 
Upvote 0 Downvote
Actually, it's going to happen in 2038, not 2036. Specifically, 19 Jan 2038 at 3:14:07 AM GMT.

You may have gotten 2036 from something talking about John Titor, a time traveller from 2036 who came (or will come) back to 1975 to grab a IBM 5100 needed to read some old IBM code in the future. Since he mentioned something about the 2038 bug while he was hanging around 2000, there's probably some conflation going on, there.
 
Upvote 0 Downvote
Hi,

Here a some code to illustartes what will happen :
Code: 
perl -e '
use POSIX;
$ENV{'TZ'} = "GMT";
for ($second= 2147483641; $second< 2147483651; $second++) {
print $second,"\t", ctime($second);
}
'

The results :
Code: 
2147483641      Tue Jan 19 03:14:01 2038
2147483642      Tue Jan 19 03:14:02 2038
2147483643      Tue Jan 19 03:14:03 2038
2147483644      Tue Jan 19 03:14:04 2038
2147483645      Tue Jan 19 03:14:05 2038
2147483646      Tue Jan 19 03:14:06 2038
2147483647      Tue Jan 19 03:14:07 2038
2147483648      Tue Jan 19 03:14:07 2038
2147483649      Tue Jan 19 03:14:07 2038
2147483650      Tue Jan 19 03:14:07 2038

2147483647 Tue Jan 19 03:14:07 2038
This is the highest epoch date in 32bits machine libraries.
 
Upvote 0 Downvote
Hi,

I've got a 64-bit computer, Tru64 Unix on an alpha EV6.7 processor.
So I tried aau's code, and here is the result:
Code: 
2147483641      Tue Jan 19 04:14:01 2038
2147483642      Tue Jan 19 04:14:02 2038
2147483643      Tue Jan 19 04:14:03 2038
2147483644      Tue Jan 19 04:14:04 2038
2147483645      Tue Jan 19 04:14:05 2038
2147483646      Tue Jan 19 04:14:06 2038
2147483647      Tue Jan 19 04:14:07 2038
2147483648      Fri Dec 13 21:45:52 1901
2147483649      Fri Dec 13 21:45:53 1901
2147483650      Fri Dec 13 21:45:54 1901
hm ...
not happy about this ...

I guess the 64 in Tru64 is not quite Tru ...
 
Upvote 0 Downvote
On an IBM p510 (64-bit, AIX 5.2):

2147483641 Tue Jan 19 03:14:01 2038
2147483642 Tue Jan 19 03:14:02 2038
2147483643 Tue Jan 19 03:14:03 2038
2147483644 Tue Jan 19 03:14:04 2038
2147483645 Tue Jan 19 03:14:05 2038
2147483646 Tue Jan 19 03:14:06 2038
2147483647 Tue Jan 19 03:14:07 2038
2147483648 Tue Jan 19 03:14:07 2038
2147483649 Tue Jan 19 03:14:07 2038
2147483650 Tue Jan 19 03:14:07 2038

As it happens, 19th Jan is my birthday, assuming I'll be around to see it!!! Star for aau.
 
Upvote 0 Downvote
It's not as simple as that. Just having a 64-bit system does not change the definition of the time data structure in the kernel. My C is a little rusty, but I believe that is defined in /usr/include/sys/types.h. Once this is extended, every single object in the OS and every application would have to be recompiled and tested with the new structure... not a trivial task!

Annihilannic.
 
Upvote 0 Downvote
It may be beacuse I'll be 75 at that time so it won't bother me professionally but if technological innovation and the rate of change of rate of change increases at it's current higher than exponential rate the systems will be so different that they won't be using the old types.h

Or maybe I'm taking the same over optomistic 'head in the sand' attitude that ended up making us all so rich workign on the Y2K bug!

Columb Healy
 
Upvote 0 Downvote
That's 30 years away. Think back 30 years. Where were all these PC desktop machines then. I was just starting on an NCR Criterion running a 'B3 O/S'. I'd venture most of you were working on a similar type of mainframe, writing in Cobol, Assembler, Fortran, or the like. As far away from C, C++, GUI, Java, Windows, Apple, OOP, and Unix as we could possibly be.

Surely someone will have enough fore-sight to solve this issue by then. There will probably be at least a couple more versions of whatever?? Unix released by then. ::)

JP
 
Upvote 0 Downvote
Well, just 20 years ago (mid 80's) I was working for a bank and they had already dealt with the Y2k problem long before I started there. An average mortgage at that time was 30 years, so we were dealing with loans that still haven't been paid off to this day.

I also worked on DEC VAX and Alpha machines running VMS/OpenVMS as Y2k was approaching. I remember writing a little program in C to find the maximum date VMS could handle internally. I don't remember the exact year, but I remember is was well over the year 36000. Yes, that's 36 thousand. I'll definitely be retired by then.
 
Upvote 0 Downvote
Hey Guys,

Does it affect any of Microsoft OS's?
 
Upvote 0 Downvote
SamBones is right. Although we didn't hit Y2K until 1995, we still saw it early. In our case, it was contract expiration dates, and we often signed 5 year contracts. Anything longer was an evergreen contract which had no expiration. Mortgage companies must be aware that this situation could cause a problem in 3 +/- years. Star for SamBones.

-------------------------
The trouble with doing something right the first time is that nobody appreciates how difficult it was - Steven Wright
 
Upvote 0 Downvote
Yes johnherman, but just because an OS is not capable of running beyond 2036, doesn't mean an application or RDBMS which runs on top of that OS can't store or process dates beyond 2036 right now...

HTH,

p5wizard
 
Upvote 0 Downvote
I believe Oracle's internal DATE format tops out at the year 9999. (Correct me if I'm wrong DBAs).
 
Upvote 0 Downvote
postgresql:
Code: 
kram=# \d d
       Table "public.d"
 Column |  Type   | Modifiers
--------+---------+-----------
 zeit   | date    |
 id     | integer |

kram=# select * from d;
     zeit      | id
---------------+----
 9999-12-31    |  1
 19999-12-31   |  2
 99999-12-31   |  3
 999999-12-31  |  4
 9999999-12-31 |  5
(5 rows)

-- but surprise:
kram=# select * from d where zeit >= '999999-12-31';
     zeit     | id
--------------+----
 999999-12-31 |  4
(1 row)
-- where is row with id=5?

seeking a job as java-programmer in Berlin:
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

ziggy6
  • Locked
  • Question
Help using awk or some kind of Tool in Unix to Read a file, cut fields and write to a file
Replies
2
Views
713
mikrom
mikrom
singaaravelup
  • Locked
  • Question
Need help on UNIX
Replies
0
Views
581
singaaravelup
singaaravelup
mduddytel
  • Locked
  • Question
Unix Root inbox - how to clear
Replies
0
Views
566
mduddytel
mduddytel
mduddytel
  • Locked
  • Question
SCO Unix Smart-host problem (?)
Replies
0
Views
540
mduddytel
mduddytel
MikeDave888
  • Locked
  • Question
Get incorrect days between two dates in UNIX 1
Replies
6
Views
630
SamBones
SamBones

Part and Inventory Search

Sponsor

Back
Top