# The Year 2038 Problem - Unix

This is a discussion on The Year 2038 Problem - Unix ; "corrlens" wrote in message news:CKqtc.12838\$Tn6.3624@newsread1.news.pas.earth link.net... > > "Guillaume" wrote in message > news:40b630cd\$0\$315\$7a628cd7@news.club-internet.fr... > > > In 2038 all OS (Unix included) will have 64 bits > > > to hold a Date value and with 64 bits the ...

# Thread: The Year 2038 Problem

1. ## Re: The Year 2038 Problem

"corrlens" wrote in message
>
> "Guillaume" wrote in message
> news:40b630cd\$0\$315\$7a628cd7@news.club-internet.fr...
> > > In 2038 all OS (Unix included) will have 64 bits
> > > to hold a Date value and with 64 bits the rollover
> > > will happen 292 billion years after 1/1/1970.

> >
> > Which is why we probably won't ever need any more than
> > 64 bits to hold dates.
> >
> > Our galaxy will probably have collapsed by then, and
> > maybe along with the whole universe.

>
> Hoping we haven't contacted any kind of higher intelligence Humans from
> other planet and they want us to modify our date to theirs.

Especially if they happen to be trans-dimensional beings with Multiverse
time / space co-ordinate expectations that require 2048 quad-bit timeline
calculations.

But perhaps we could just send a few Christians over and get them all to
convert to Jesus Time (r).

--
Mabden

2. ## Re: The Year 2038 Problem

"T.M. Sommers" wrote in message news:<0qKdnQpLjrhHwyvdUSdV9g@telcove.net>...
> Dan Pop wrote:
> >
> > So, what's the next massive problem we have to worry about, now that we
> > have just solved this one?

>
> The Y10K problem, when all those 4-digit years everyone is so
> proud of become obsolete. If it took several years to fix just
> 40 years worth of software for the Y2K problem, just think how
> long it will take to fix 8000 years worth of software for the
> Y10K problem. We had better get started right away. There is no
> time to lose.

Actually, the next big date problem is the Y2100 problem (at least for
those who aren't still concerned about Y2K, which is still 44 years
away). Many programs still assume that any year that's evenly
divisible by 4 is a leap year.

Fambright

3. ## Re: The Year 2038 Problem

> Actually, the next big date problem is the Y2100 problem (at least for
> those who aren't still concerned about Y2K, which is still 44 years
> away). Many programs still assume that any year that's evenly
> divisible by 4 is a leap year.

That's a small date problem, easily corrected. All it takes is an
amendment of a tiny expression to a still not complicated expression.
No changes to any interface are needed, so this is very straightforward
to put into effect.

Richard

4. ## Re: The Year 2038 Problem

I do not think that t was ever equal to zero,
t only approches zero.
rossum wrote:

> On 27 May 2004 21:27:14 GMT, gordonb.xoh7d@burditt.org (Gordon
> Burditt) wrote:
>
>
>>>[snip]
>>>

>>My personal preference would be for a 256-bit number of picoseconds since
>>the creation of the universe. It gives better precision than 1 second.
>>It won't run out during the life of this universe. The only trouble is,
>>we don't know accurately when that was.
>>
>>
>> Gordon L. Burditt
>>

> < mode = nitpick >
> Not quite accurate. We know precisely when the universe started; at
> time = 0. The problem is that we don't know what the time is now.
> < mode = whatever_passes_for_normal >
>
> rossum
>
> --
>
> The Ultimate Truth is that there is no Ultimate Truth
>

5. ## Re: The Year 2038 Problem

Not only must the year be divisible by 4, if it is a century
year it must be divisible by 400.

> "T.M. Sommers" wrote in message news:<0qKdnQpLjrhHwyvdUSdV9g@telcove.net>...
>
>>Dan Pop wrote:
>>
>>>So, what's the next massive problem we have to worry about, now that we
>>>have just solved this one?
>>>

>>The Y10K problem, when all those 4-digit years everyone is so
>>proud of become obsolete. If it took several years to fix just
>>40 years worth of software for the Y2K problem, just think how
>>long it will take to fix 8000 years worth of software for the
>>Y10K problem. We had better get started right away. There is no
>>time to lose.
>>

>
> Actually, the next big date problem is the Y2100 problem (at least for
> those who aren't still concerned about Y2K, which is still 44 years
> away). Many programs still assume that any year that's evenly
> divisible by 4 is a leap year.
>
>
> Fambright
>

6. ## Re: The Year 2038 Problem

"Gerry Quinn" wrote in message
news:MPG.1b20ff0fcc0166cf989681@news.indigo.ie...
> In article ,
> xxxxxxx@yyyyyyy.com says...
> > "Generic Usenet Account" wrote in message
> > < snip >
> > > Although the Y2K scare turned out to be vastly overblown,

> > < snip >
> >
> > Idiot!! It wasn't "vastly overblown" at all. The fact is,
> > we did a damn good job fixing it.

>
> In countries where little or no effort was put into preventing it, no
> significant problems occurred either.
>
> "Only the vigilance of our firefighters has prevented this 2000-year old
> forest from burning to the ground dozens of times over the last decade!"
>
> - Gerry Quinn

Pull your head out of the sand for a moment, and take
a look at: http://www.grantjeffrey.com/article/y2kretro.htm

-- Bob Day

7. ## Re: The Year 2038 Problem

In Ben Measures writes:

>Otto Wyss wrote:
>> Dan Pop wrote:
>>>Nope, this won't happen. By then, time_t will be a 64-bit type, as it
>>>already is on some 64-bit platforms (e.g. all 64-bit Linux ports):

>>
>> The time_t might have 64-bit but are you sure that every occurence where
>> the time is copied or used is as well?

>
>By 2038 opensourced software will be abundant and everyone will laugh at
>those still using proprietry software ;->

Guess what? Even proprietary software is maintained.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

8. ## Re: The Year 2038 Problem

In gordonb.xoh7d@burditt.org (Gordon Burditt) writes:

>My personal preference would be for a 256-bit number of picoseconds since
>the creation of the universe. It gives better precision than 1 second.
>It won't run out during the life of this universe. The only trouble is,
>we don't know accurately when that was.

Does it matter?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

9. ## Re: The Year 2038 Problem

In "myren, lord" writes:

>Guillaume wrote:
>>> In 2038 all OS (Unix included) will have 64 bits
>>> to hold a Date value and with 64 bits the rollover
>>> will happen 292 billion years after 1/1/1970.

>
>> Which is why we probably won't ever need any more than
>> 64 bits to hold dates.

>
>> Our galaxy will probably have collapsed by then, and
>> maybe along with the whole universe.

>
>God forbid I'm not running at least 256 bits by then.

Yeah, but that would be a 64-bit x 4 vector processor ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

10. ## Re: The Year 2038 Problem

In Gerry Quinn writes:

>In article ,
>xxxxxxx@yyyyyyy.com says...
>> "Generic Usenet Account" wrote in message
>> < snip >
>> > Although the Y2K scare turned out to be vastly overblown,

>> < snip >
>>
>> Idiot!! It wasn't "vastly overblown" at all. The fact is,
>> we did a damn good job fixing it.

>
>In countries where little or no effort was put into preventing it, no
>significant problems occurred either.

A country generating no significant software products has nothing to fix.
It's as simple as that.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

11. ## Re: The Year 2038 Problem

"Corey Murtagh" wrote in message
> AngleWyrm wrote:
> > My solution is that I plan to be dead around 2040 or so.

>
> 15 years after the oil runs out and we're all paying US\$20/gallon for

I assume that \$20 is after inflation, which means it'll be on par (in
constant dollars) with what we pay for petrol or ethanol today. Hardly a
problem, though I'd expect us all to be running on hydrogen by then; ethanol
is a transition fuel.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

12. ## Re: The Year 2038 Problem

On 27 May 2004 21:27:14 GMT, gordonb.xoh7d@burditt.org (Gordon Burditt)
wrote:

>My personal preference would be for a 256-bit number of picoseconds since
>the creation of the universe. It gives better precision than 1 second.
>It won't run out during the life of this universe. The only trouble is,
>we don't know accurately when that was.

That's ok, we probably know it to at least the same relative accuracy as
January 1, 1970 "accurately" mirrors the beginning of the Unix era.
-leor

>
>
> Gordon L. Burditt

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
www.bdsoft.com/tools/stlfilt.html

13. ## Re: The Year 2038 Problem

In article ,
xxxxxxx@yyyyyyy.com says...
> "Gerry Quinn" wrote in message

> > > > Although the Y2K scare turned out to be vastly overblown,
> > > < snip >
> > >
> > > Idiot!! It wasn't "vastly overblown" at all. The fact is,
> > > we did a damn good job fixing it.

> >
> > In countries where little or no effort was put into preventing it, no
> > significant problems occurred either.

>
> Pull your head out of the sand for a moment, and take
> a look at: http://www.grantjeffrey.com/article/y2kretro.htm

LOL! That article was written a mere ten days into the year 2000 by tha
author of "The Millenial Meltdown", and already he was running for
cover. He should have waited a few days, some of his his followers
might not have been down from the hills in time to read it.

He had no significant examples of serious failures to report, so he
started pushing that good old line "If it wasn't serious why did we
spend so much?". Nearly all the article is just "Everybody else said it
was serious too".

"Those who naively suggest that Y2K was all hype should ask themselves
why banks (who are not generally known to throw their money away) would
spend literally hundreds of millions of dollars and hundreds of
thousands of man hours to fix the problem..."

You know, banks *aren't* known for throwing their money away - they've
got plenty of yours and mine for that! Barings, for example, or AIB.

There was a Feb 29 bug in 2000 that wasn't hyped at all, and little
enough went wrong that day either.

Truth is the Millenium Bug Disaster was a '60s science fiction scenario,
based on the assumption that all the operations that keep the industrial
world turning are done by technicians blindly obeying the orders on
punched cards that some big old computer spits out. The real world is
considerably more fault tolerant.

- Gerry Quinn

14. ## Re: The Year 2038 Problem

Stephen Sprunk wrote:
> "Corey Murtagh" wrote in message
>

.... snip ...
>>
>> 15 years after the oil runs out and we're all paying
>> US\$20/gallon for vehicle grade alcohol :>

>
> I assume that \$20 is after inflation, which means it'll be on par
> (in constant dollars) with what we pay for petrol or ethanol
> today. Hardly a problem, though I'd expect us all to be running
> on hydrogen by then; ethanol is a transition fuel.

And where does the power to extract that hydrogen come from? In
case you hadn't noticed it does not tend to occur in free form in
nature. However, it can serve as an intermediary between real
renewable sources and portable machinery.

--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchison

15. ## Re: The Year 2038 Problem

Stephen Sprunk wrote:

> "Otto Wyss" wrote in message
> news:1gegpbt.ot7t0q1p5gqogN%otto.wyss@orpatec.ch.. .
> > The time_t might have 64-bit but are you sure that every occurence where
> > the time is copied or used is as well?

>
> If someone copies a time_t into a variable of any other type, they may be
> invoking undefined behavior, which means it's not the Standard's problem,
> it's the coder's.
>
> time_t exists for a reason, just like size_t. Use them.
>

I don't hope time_t isn't as often converted to int as size_t is. Well I
guess it won't be that big problem, I just wanted to point out that you
never should assume what other coders think.

O. Wyss

--
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

16. ## Re: The Year 2038 Problem

Ben Measures wrote:

> Otto Wyss wrote:
> > The time_t might have 64-bit but are you sure that every occurence where
> > the time is copied or used is as well?

>
> By 2038 opensourced software will be abundant and everyone will laugh at
> those still using proprietry software ;->

Whow perfect! I'll see that my OpenSource projects are finished be then.

O. Wyss

--
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

17. ## Re: The Year 2038 Problem

On 2004-05-28, Stephen Sprunk wrote:
> "Corey Murtagh" wrote in message
>> AngleWyrm wrote:
>> > My solution is that I plan to be dead around 2040 or so.

Hm I might not make that. Fun prospect!

>> 15 years after the oil runs out and we're all paying US\$20/gallon for

>
> I assume that \$20 is after inflation, which means it'll be on par (in
> constant dollars) with what we pay for petrol or ethanol today. Hardly a
> problem, though I'd expect us all to be running on hydrogen by then; ethanol
> is a transition fuel.

The fun thing of course is that alcohols are about the simplest things
to make, and dead cheap too. The only thing that make them so darn
expensive is the various governements wanting a piece of the action, in
the interest of letting people have less fun for their dollar.

Fact is, oil is not as cheap as it seems, as it has rather high cleanup
costs associated with it. Same with nuclear fuels, but oil doesn't have
quite such spectacular faillure modes. Altough I have to admit that
fuel/air bombs are kinda neat. And oily birds make for nice television
and cause traffic jams with people driving to a different, clean beach.

Same with our silicon based computing stuffs. They and the facilities
needed to produce them are not very environment friendly, and the
pittance some of us now have to pay as advance clean-up costs will not
be enough to fix the problems the obsoleted debris will create later on.

Anyway. Whatever we do, we'll pay for it sooner or later. If sufficiently
late we'll just be cursed by our ancestors. Which would you prefer?

--
j p d (at) d s b (dot) t u d e l f t (dot) n l .

18. ## Re: The Year 2038 Problem

"Otto Wyss" wrote in message
> Stephen Sprunk wrote:
>
> > "Otto Wyss" wrote in message
> > news:1gegpbt.ot7t0q1p5gqogN%otto.wyss@orpatec.ch.. .
> > > The time_t might have 64-bit but are you sure that every occurence

where
> > > the time is copied or used is as well?

> >
> > If someone copies a time_t into a variable of any other type, they may

be
> > invoking undefined behavior, which means it's not the Standard's

problem,
> > it's the coder's.
> >
> > time_t exists for a reason, just like size_t. Use them.
> >

> I don't hope time_t isn't as often converted to int as size_t is. Well I
> guess it won't be that big problem, I just wanted to point out that you
> never should assume what other coders think.

Neither time_t nor size_t is ever converted to int in code I write or
maintain; I can't speak to what others do...

With the growing adoption of 64-bit desktops we already see bugs where
people improperly convert size_t to int, at least on platforms where int
isn't also 64-bit (i.e. AMD64). We'll find out how many people don't use
time_t correctly in 2038

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

19. ## Re: The Year 2038 Problem

"CBFalconer" wrote in message
news:40B751E8.17B69272@yahoo.com...
> Stephen Sprunk wrote:
> > I assume that \$20 is after inflation, which means it'll be on par
> > (in constant dollars) with what we pay for petrol or ethanol
> > today. Hardly a problem, though I'd expect us all to be running
> > on hydrogen by then; ethanol is a transition fuel.

>
> And where does the power to extract that hydrogen come from? In
> case you hadn't noticed it does not tend to occur in free form in
> nature. However, it can serve as an intermediary between real
> renewable sources and portable machinery.

Hydrogen isn't the original source; however, it is a clean, portable way to
store and transport energy generated by some other means. Depending on the
original source, the entire system may or may not be clean, and there's
varying values of "clean" as well.

Ethanol is mainly interesting because it has almost the same energy density
as petrol, has about the same price, runs in the same engines without
modification (though the fuel system needs anti-corrosion protection), uses
the same transport and fueling infrastructure, and can be produced nearly
anywhere in the world. While ethanol is far cleaner than petrol, it's
nowhere near as clean as hydrogen even if you consider waste generated in
producing the latter.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

20. ## Re: The Year 2038 Problem

I am not sure hyow hydrogen would be ditributed,
either to the resellers (filling stations)
or regionally (to terminals).
Gasoline is distributed to terminals via pipelines.
MTBE is also distributed via pipelines. But MTBE
pollutes ground water.
Ethanol is shipped via trucks, no pipelines.

Any thoughts on hydrogen distribution?

Stephen Sprunk wrote:

> "CBFalconer" wrote in message
> news:40B751E8.17B69272@yahoo.com...
>
>>Stephen Sprunk wrote:
>>
>>>I assume that \$20 is after inflation, which means it'll be on par
>>>(in constant dollars) with what we pay for petrol or ethanol
>>>today. Hardly a problem, though I'd expect us all to be running
>>>on hydrogen by then; ethanol is a transition fuel.
>>>

>>And where does the power to extract that hydrogen come from? In
>>case you hadn't noticed it does not tend to occur in free form in
>>nature. However, it can serve as an intermediary between real
>>renewable sources and portable machinery.
>>

>
> Hydrogen isn't the original source; however, it is a clean, portable way to
> store and transport energy generated by some other means. Depending on the
> original source, the entire system may or may not be clean, and there's
> varying values of "clean" as well.
>
> Ethanol is mainly interesting because it has almost the same energy density
> as petrol, has about the same price, runs in the same engines without
> modification (though the fuel system needs anti-corrosion protection), uses
> the same transport and fueling infrastructure, and can be produced nearly
> anywhere in the world. While ethanol is far cleaner than petrol, it's
> nowhere near as clean as hydrogen even if you consider waste generated in
> producing the latter.
>
> S
>
>