Searching \ for '[OT] Y2K38' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=y2k38
Search entire site for: 'Y2K38'.

Exact match. Not showing close matches.
PICList Thread
'[OT] Y2K38'
2005\12\13@150419 by Jinx

face picon face
"Computer experts say the wired world will turn upside down in January 2038,
a date that seems far away but is already being accessed by computers to
log in land leases and commercial agreements. The problem is akin to that
of Y2K, only this time it is for real, warn experts. Experts have set the
disaster time for computers at 03:14:07 GMT, January 19, 2038, a Tuesday.
At that moment, many computers will "run out of time." The next second,
they will begin showing the time as 8:45:52 PM GMT, December 13, 1901.

If you are willing to take a risk and crash your computer, you could try
the following exercise: change your computer system date to January 19,
2038, and time to 03:14:07 or beyond, and send a message on Yahoo
Messenger. The messenger crashes. Chances are that if you are using
Internet Explorer, it could get corrupted. All network-based applications
could stop functioning.

The 2038 problem affects programs that use the Posix time representation,
which represents time as the number of seconds since January 1, 1970. This
representation is standard in Unix-like operating systems and also affects
software written for most operating systems because of the broad deployment
of C.

"In case you think we can sit on this issue for another three decades
before addressing it, consider that reports of temporal echoes of the 2038
problem are already starting to appear in future date calculations for
mortgages and vital statistics," said M.H. Noble, managing director of Zoom
Technologies (India) Ltd. What actually is the 2038 problem and how does it
strike? Be prepared for a little lesson in programming.

Time_t is a data type used by C and C++ programs to represent time. Time_t
is a count of the number of seconds since 1200 GMT on January 1, 1970.
Time_t 0 would be midnight of January 1, 1970, time_t value of 1 would be
12:00:01 am of January 1, 1970. By the time the world moves to 2038, the
time_t value will be over 2,140,000,000.

And therein lies the problem. A modern 32-bit computer stores a "signed
integer" data type, such as time_t, in 32 bits. The first of these bits is
used for the positive/negative sign of the integer, while the remaining 31
bits are used to store the number itself. The highest number that 32-bit
computers can store in C and C++ based programs is 2,147,483,647. In time_t
terms, it translates to 3:14:07 GMT, January 19, 2038. At that moment,
time_t in a 32-bit C or C++ program will reach its upper limit. Or the
computer will run out of time. One second later, on January 19, 2038, at
3:14:08 GMT, disaster strikes, explains Murali Krishna of Hutch. Every time
the calculation goes haywire.

The next second is represented as minus-2,147,483,648, and the computer
does not understand this. Thrown in a tizzy, it "thinks" that the time is
8:45:52 PM GMT, December 13, 1901. So, according to the soothsayers,
January 19, 2038, will turn into December 13, 1901. Every date calculation
will go haywire. And it gets worse. Most of the support functions that use
the time_t data type cannot handle negative time_t values at all. They
simply fail and return an error code.


But some experts say there is nothing to worry about. Says senior
mathematician B. Moinuddin: "The problem is only with 32-bit computers.
Anyhow 64-bit computers are going to be the norm in just a few years, let
alone 34 years. We need not go into the panic mode. There is time to
resolve this issue in a calm, cool and collected manner. Y2K was definitely
blown way out of proportion. This too is going to be that way"

2005\12\13@172544 by Robert Rolf

picon face
So why isnt' Time_t stored as an UNSIGNED integer since time
cannot be negative? Gives us another 68 years ;-).

And what kind of 'expert' says "the problem is only with 32 bit
computers. 64 bit computers will be the norm in a few years"?
The problem occurs TODAY with long term date calculations like
mortgages and land leases and life insurance.
Y2K wasn't the disaster it _could_ have been because of the
"overreaction" that had key systems compliant by the rollover date.

I use a old DOS assembler to support 10 year old HC11 code,
and it says the listings were made 11-22-105 so the Y2K bug is
still with us, even on a modern 64bit machine (running ancient
code).

Just my few kajillion electrons worth.
Robert


Jinx wrote:
{Quote hidden}

2005\12\13@173955 by Jinx

face picon face
> And what kind of 'expert' says "the problem is only with 32 bit
> computers. 64 bit computers will be the norm in a few years"?
> The problem occurs TODAY with long term date calculations

Of course - the problem is in the s/w, not the h/w. Sounds like an
excellent source of income (in the right niche), a la Y2K

2005\12\13@174150 by Wouter van Ooijen

face picon face
> The problem is akin to that
> of Y2K, only this time it is for real, warn experts.

ROFL! Like a politician saying "this time I am honest, realy!".

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\12\13@174323 by Danny Sauer

flavicon
face
Robert wrote regarding 'Re: [OT] Y2K38' on Tue, Dec 13 at 16:28:
> And what kind of 'expert' says "the problem is only with 32 bit
> computers. 64 bit computers will be the norm in a few years"?

Experts know that switching to 64-bit native computers will magically
recompile all programs to use 64-bit ints.  Even programs that depend
on the size of structures internally will suddenly be converted.  The
experts know that this is the obvious solution, since it will mean no
one has to bother changing the header where time_t is defined.  I
think that's silly, but I'm no expert.

Of course, it's foolish to assume that 32-bit computers could use
64-bit integer representations - that's like trying to plug a Nintendo
Game Cube game into a Sega Master System.  Duh, that won't work!  It
doesn't have enough bits!  Those silly old 32-bit computers will be
thrown into the trash like so many Colecovision consoles, when the
revolution comes.

--Danny, who hates the news media

2005\12\13@183347 by olin piclist

face picon face
Robert Rolf wrote:
> So why isnt' Time_t stored as an UNSIGNED integer since time
> cannot be negative? Gives us another 68 years ;-).

Because generic C coders don't think of specifying UNSIGNED.  It's also
probably not specifically a 32 bit integer, probably just INT in whatever
compiler the OS was compiled with, which could change.  This is another
thing C coders rarely consider.

> And what kind of 'expert' says "the problem is only with 32 bit
> computers. 64 bit computers will be the norm in a few years"?
> The problem occurs TODAY with long term date calculations like
> mortgages and land leases and life insurance.

Only when people were dumb enough to use the TIME_T data type directly.  I
realized this was a problem with various operating systems long ago (by the
way, the Domain/OS rollover already occurred something like 10 years ago).
Lots of operating systems do it in a different way.  There are differences
between Unix systems too if I remember right.  I don't remember what Windows
uses internally, but it's probably not the same.

I've been using a portable time specifier for something like 15 years now.
It's fixed point 60.30 seconds since the start of year 2000.  Yes that means
it was negative when I first started using it and it's now positive.  As
different operating systems for getting the time change, all I have to do is
rewrite one routine that converts from the local system method to the
portable time specifier and all the rest of my code will just work.  Here is
the excerpt from my SYS library include file that defines the portable time
descriptor:

{
*   Clock time descriptor.  This descriptor can hold either an absolute or
*   relative time value.  It is the low level portable time descriptor.
*   An absolute value of zero indicates the start of the year 2000.
*
*   The time descriptor is a 60.30 fixed point number, representing seconds.
*   Since 90 bit numbers are not generally available, 3 fields of 30 bits
each
*   are used.  The time value is stored as a twos complement number.
*
*   The time descriptor therefore has a resolution of 2**(-30) seconds, or
*   about 931 pico seconds.  It has a maximum value of 2**59 seconds, or
*   about 18 billion years.  (Current scientific estimates put the age of
*   the universe at around 15 billion years, and Earth's age at 4.5 billion
*   years).
}
 sys_clock_t = record                 {portable absolute or relative clock
values}
   high: 0..1073741823;               {2**30 seconds}
   sec: 0..1073741823;                {whole seconds}
   low: 0..1073741823;                {fractions of a second, units of
2**(-30) sec}
   rel: boolean;                      {TRUE for relative time value}
   end;
 sys_clock_p_t = ^sys_clock_t;


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\12\13@183858 by Jinx

face picon face
> --Danny, who hates the news media

Y2K38 is hardly a disaster when we're all going to die of
bird flu long before then anyway


2005\12\13@190018 by M Graff

flavicon
face
Olin Lathrop wrote:
> Robert Rolf wrote:
>
>> So why isnt' Time_t stored as an UNSIGNED integer since time
>> cannot be negative? Gives us another 68 years ;-).
>
>
> Because generic C coders don't think of specifying UNSIGNED.  It's also
> probably not specifically a 32 bit integer, probably just INT in whatever
> compiler the OS was compiled with, which could change.  This is another
> thing C coders rarely consider.

You're an engineer, right?

What happens when you want to get the number of seconds between two
signed integers, or see if they are out of bounds?

When you USE time_t, you tend to do math on it.  Saying

       time_t diff = a - b;

and allow diff to be negative certainly seems more forward-thinking than
saying "why can't they think of this stuff?"

Really, all that needs to happen is a new version of time_t that is
64-bits long.  time64_t or something.

>> And what kind of 'expert' says "the problem is only with 32 bit
>> computers. 64 bit computers will be the norm in a few years"?
>> The problem occurs TODAY with long term date calculations like
>> mortgages and land leases and life insurance.

Any reasonably modern SQL-based system will be able to handle any
four-digit year.  This is hype.  Read it as "the media got bored of the
war on terror and decided to scare us in other ways for a while."

--Michael

2005\12\13@230120 by Paul Hutchinson

picon face
I just set the date to 2060 on Win XP while Outlook 2000 was running. I got
alerts for missed appointments but all worked fine. I next fired up IE and
surfed, it was fine. I then shutdown Outlook and restarted it, still working
OK.

Next I rebooted to see if the bios could handle 2060 and it works (ASUS
A7N8X-E Deluxe with Phoenix BIOS). WinXP also booted just fine.

This is as I expected since Microsoft dealt with this issue back in the
1990's by providing and encouraging the use of the date data type for both
VB and VC++.

Paul
Who will likely be dead before 2038 and if not, definitely retired :-).

> {Original Message removed}

2005\12\14@004056 by Jose Da Silva

flavicon
face
On December 13, 2005 08:01 pm, Paul Hutchinson wrote:
> I just set the date to 2060 on Win XP while Outlook 2000 was running.
> I got alerts for missed appointments but all worked fine. I next
> fired up IE and surfed, it was fine. I then shutdown Outlook and
> restarted it, still working OK.

If those are the only applications you use, then yes, your computer is
fine. You may or might not find other applications that do or don't
work correctly.  ;-)     YMMV

The problem, is applications written which follow or don't follow
certain traditions, for example, this does not matter if it's windows,
unix or anything else including embedded pics or other computers:

"The first time I saw this in someone else's code I wondered why they
took such a goofy approach. But then I realized it never fails! The
subtraction is done first, and as"
http://www.embedded.com/showArticle.jhtml?articleID=57703680

The above is worth noting, even for the pic TMR0 since it's better for 2
reasons to let the TMR0 freewheel on it's own versus you resetting it
with a constant and waiting to reach a constant. The 1st reason is as
stated in the article, the 2nd reason is you reset the divider circuits
every time you load TMR0 with a value, which means not exact timing is
maintained.

> Next I rebooted to see if the bios could handle 2060 and it works
> (ASUS A7N8X-E Deluxe with Phoenix BIOS). WinXP also booted just fine.

This is expected for a recent model of computer and bios.  ;-)
If your computer was built before 1995, you might see problems since the
bios clock reserved very little memory for the clock (the problem would
show-up going from 1999 to 2000 since only 1byte in bcd format was used
to store the year).
Bios clocks today have enough digits to deal with 2000 or beyond.
The bios clock and the unix 32bit standard-time are really 2 different
systems, so it's comparing apples to oranges.

Cheers

2005\12\14@014137 by William Chops Westfield

face picon face
There's so much wrong here it's very sad....

On Dec 13, 2005, at 12:06 PM, Jinx wrote:

> the wired world will turn upside down in January 2038,

Well, duh.  Unix programmers have been talking about this since
everyone else was still talking about Y2K.


> The problem is akin to that of Y2K, only this time it is for real

Y2K was a 'for real' problem.  It just wasn't as DIRE as some worried,
and it was mostly fixed by the time Y2K came around in spite of
predictions
of unnoticed programs that would fail catastrophically.

> The 2038 problem affects programs that use the Posix time
> representation,
> which represents time as the number of seconds since January 1, 1970.

The internal representation of time within a program tends to be
relatively unimportant compared to the representation used in databases
and external forms.  I think time_t data is rarely stored in binary
databases as such.  (a 4-digit ascii date takes up the same space.)

> consider that reports of temporal echoes of the 2038 problem are
> already starting to appear in future date calculations for mortgages
> and vital statistics,"

Funny, though. You'd think there  would have been the same issues with
mortgages and such for Y2k back around 1970 and continually thereafter,
but I don't recall hearing anything till Y2K was "imminent".

> The next second is represented as minus-2,147,483,648, and the computer
> does not understand this. Thrown in a tizzy, it "thinks" that the time
> is
> 8:45:52 PM GMT, December 13, 1901. So, according to the soothsayers,
> January 19, 2038, will turn into December 13, 1901. Every date
> calculation
> will go haywire.

Actually, a good number of the calculations will work fine, though they
might pop up as overflow errors.  I/O might get screwed up.  Stuff that
converts to text and does string compares might get screwed up.

>
> But some experts say there is nothing to worry about. Says senior
> mathematician B. Moinuddin: "The problem is only with 32-bit computers.
> Anyhow 64-bit computers are going to be the norm in just a few years,
> let
> alone 34 years.

Ugh.  Really bad explanation.

> We need not go into the panic mode. There is time to
> resolve this issue in a calm, cool and collected manner. Y2K was
> definitely
> blown way out of proportion. This too is going to be that way"
>
But his conclusion is essentially correct.

We (collectively) ought to be getting good at this.  The first date
field
overflow I know of happened in 1975 in the tops10 file system...

No doubt that there are some people itching to spend the next 35 years
being "expert Y2k38 consultants."  What a waste...

BillW

2005\12\14@070656 by olin piclist

face picon face
M Graff wrote:
> What happens when you want to get the number of seconds between two
> signed integers, or see if they are out of bounds?
>
> When you USE time_t, you tend to do math on it.  Saying
>
> time_t diff = a - b;
>
> and allow diff to be negative certainly seems more forward-thinking than
> saying "why can't they think of this stuff?"

Not really, since the system time value is always absolute and positive.  If
your calculations require a relative time value, which could be negative,
then you should use a data type suitable for that.  In other words in the
example above, the error is using the system absolute time data type for
DIFF.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\12\14@145606 by Peter
picon face

On Wed, 14 Dec 2005, Jinx wrote:

> The 2038 problem affects programs that use the Posix time representation,
> which represents time as the number of seconds since January 1, 1970. This
> representation is standard in Unix-like operating systems and also affects
> software written for most operating systems because of the broad deployment
> of C.

Possible discussions as to how this could be handled were held before
Y2K. It is fairly trivial to do in the C libraries, and some
applications will beed to be fixed and recompiled. That is not a problem
for open source *nix. As to legacy systems ... well they are called
legacy for a reason I guess.

If oil will really run out and no other good solution will be found,
then it is possible that most people will run crank-powered mechanical
abacuses with more than 64 bits in 35 years or so.

Peter

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...