![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Mark Gordon wrote:
> Nieminen Mika wrote:
> >
>
> > The time() function returns the time in seconds since the Epoch. The Epoch
> > is referenced to 00:00:00 CUT (Coordinated Universal Time) 1 Jan 1970.
> >
> > As you can see, there's no reference to the current year here.
> > Since this counter is usually a 32-bit number, the real problem comes
> > in 2106 when the counter overflows.
> > I think I will not live that long.
>
> Unless it's storing it as a signed integer, in which case it conks out
> in 2038. I've heard plenty of references to the 2038 problem, which I
> may very well live to see. Then again, I also expect to have migrated
> to 64-bit architectures by that time.
Or... unless you are running on some older Microsoft stuff. I've seen their calls
documented as working only up to 2035. (Trying to remember if it was in DOS or
Win31 calls). Anyway, I had seen it at some point when the first rumblings of Y2K
were being noticed by people and I was looking into the 2038 problem.
So
2038 = problems for most of the world.
2035 = problems for older MS OS users.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Mark Gordon <mtg### [at] mailbag com> wrote:
: Then again, I also expect to have migrated
: to 64-bit architectures by that time.
It took almost 10 years to microsoft to "migrate" to 32 bits and thus to
the majority of users. I seriously think that microsoft will be late again.
Of course there are alternatives... Hopefully linux will be more popular
than windows at that time.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Mark Gordon wrote:
> Unless it's storing it as a signed integer, in which case it conks out
> in 2038. I've heard plenty of references to the 2038 problem, which I
> may very well live to see. Then again, I also expect to have migrated
> to 64-bit architectures by that time.
Well, I doubt we'll have to worry about 2038 for a while. :)
By then, it's doubtful Windows will exist at all, but rather some
superior successor, probably not made by Microsoft. The whole industry
will be incredibly different, really, so worrying about 2038 right now
isn't a big deal.
Of course, this is analogous to a programmer in 1961 not worrying about
2000, and look where that got us, but the real problem comes from the
1981 and 1991 programmers not worrying about it either. We've got a
little while to put it off, as long as people begin taking care of the
problem before 2020 or so.
In 2038, as in many cases now, it's doubtful anything will be affected
beyond a few mainframes with ancient code.
Kind of ironic, actually; one of my favorite books, David Brin's
"Earth", is set in 2038. If you want a glimpse at what the Web could
become over the course of time, there's the place to look.
Lummox JR
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
The earliest Macintosh models can handle dates up to 2040, and the newer
ones can handle dates up to year 28000 or so. That is a VERY long time.
The Y28K bug. <g>
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
While I expect 32 bit, UNIX type system clocks to reset seven seconds after
3:14a.m. on Janurary 19th, 2038 - it should be a different story for 64 bit
clocks (which are being implimented as we speak) which should last beyond
the year 290,000,000,000. I don't think the phrase 'Y290g bug' will take
off though.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Edward C." wrote:
I don't think the phrase 'Y290g bug' will take off though.
Thank God !!!
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Edward C. wrote in message <3770435f@news.povray.org>...
>While I expect 32 bit, UNIX type system clocks to reset seven seconds after
>3:14a.m. on Janurary 19th, 2038 - it should be a different story for 64 bit
>clocks (which are being implimented as we speak) which should last beyond
>the year 290,000,000,000. I don't think the phrase 'Y290g bug' will take
>off though.
Just wait! And wait, and wait, and wait....
Mark
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Jon A. Cruz" wrote:
> 2038 = problems for most of the world.
Not quite. Just the unix world really. Which is far from being the whole lot.
> 2035 = problems for older MS OS users.
The following page used to be a pretty good resource in the matter :
http://www.merlyn.demon.co.uk/critdate.htm but it is such a long time since I looked
at it that I'm not sure the link is up to date.
Cheers,
Al.
--
ANTI SPAM / ANTI ARROSAGE COMMERCIAL :
To answer me, please take out the Z from my address.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Oh yeah? So the moon was 1/4 full a few weeks ago in LA when their Y2K test
resulted in all that raw sewage being strewn about?
--
Jim
Check out my web site http://www.kressworks.com/
It'll blow your mind (politically), stimulate your senses (artistically)
and provide scientific insights that boggle the mind!
Ken <tyl### [at] pacbell net> wrote in message
news:376C392B.13110C5D@pacbell.net...
>
>
> Jim Kress wrote:
> >
> > Actually, what will happen is that it will cause a huge failure at your
> > local sewage plant. You will wind up with 2,000,000 gallons of raw
sewage
> > in your yard (only if you live in Los Angeles ...) :<)
> >
> > --
> > Jim
>
> You forgot to mention this will only occur if the moon is 1/4 full
otherwise
> it happens in New York City.
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Mark Wagner wrote:
> Edward C. wrote in message <3770435f@news.povray.org>...
> >While I expect 32 bit, UNIX type system clocks to reset seven seconds after
> >3:14a.m. on Janurary 19th, 2038 - it should be a different story for 64 bit
> >clocks (which are being implimented as we speak) which should last beyond
> >the year 290,000,000,000. I don't think the phrase 'Y290g bug' will take
> >off though.
>
> Just wait! And wait, and wait, and wait....
>
> Mark
Well, given that the expected life span of our solar system is just about 5gig
years and that our whole univers is estimated to be approximately 15 gig years
old, I think we don't have to worry much about the 290gig boundary. Maybe this
should be a good opportunity to change the clock systems in computers and rather
than deal with useless stuff like 290 gig years, let the max be somewhat smaller
(say 20gig) and have a finer grain, dive further into the subdivisions of
seconds and milliseconds.
Cheers,
Al.
--
ANTI SPAM / ANTI ARROSAGE COMMERCIAL :
To answer me, please take out the Z from my address.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |