>Is POV-Ray Y2K compliant?  For example, if, using POV-Ray for Windows, I
>start a rendering on New Year's Eve, will it be successfully rendered if
>rendering continues past midnight?

I doubt that the rendering code will be affected. However, the stats may look
funny.

I'd be more worried about Windows.


 /j

Post a reply to this message

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.

-- 
Mark Gordon
mtg### [at] povrayorg

Post a reply to this message

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

Mark Gordon <mtg### [at] mailbagcom> 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

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

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

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

"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

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

"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